Il 3 agosto 2026 qualcosa di insolito ha iniziato ad attraversare i filtri antispam di centinaia di organizzazioni statunitensi: oltre un milione di email di richiesta pagamento, tutte diverse tra loro, tutte credibili, tutte generate in appena tre giorni. Non è la solita campagna di #phishing a basso costo con errori grammaticali e loghi sgranati: secondo il report pubblicato dal Microsoft Threat Intelligence Center il 10 settembre 2026, dietro questa ondata di frodi BEC (Business Email Compromise) ci sono chiari indizi dell’uso di modelli linguistici generativi per scrivere, personalizzare e scalare l’inganno.

Per chi amministra infrastrutture di posta elettronica e sistemi di sicurezza, questa campagna è un caso di studio prezioso: mostra sia quanto l’AI stia alzando la qualità media degli attacchi di ingegneria sociale, sia quali segnali tecnici restano comunque rilevabili, se si sa dove guardare.

Anatomia della campagnaI ricercatori Microsoft hanno ricostruito una timeline precisa. Gli attaccanti hanno registrato domini “lookalike” — pensati per assomigliare a fornitori o partner legittimi — il 31 luglio 2026, pochi giorni prima del lancio operativo. Tra il 3 e il 5 agosto sono state distribuite oltre un milione di email, con l’87,7% dei destinatari concentrato negli Stati Uniti.

Il bersaglio era il personale degli uffici contabilità fornitori (accounts payable): le email si spacciavano per comunicazioni di dirigenti — CEO, CFO — che sollecitavano bonifici ACH da circa 50.000 dollari, corredati da fatture false con branding contraffatto (in diversi casi imitando ServiceNow) e sezioni “Fatturato a” personalizzate con il nome dell’azienda bersaglio.

Come si riconosce la mano dell’AIIl dato più interessante per chi fa detection non è “che è stata usata l’AI”, ma come lo si vede. Microsoft ha individuato pattern strutturali tipici della generazione automatica di contenuti:

Commenti HTML estesi che descrivono le sezioni del messaggio, tipicamente residui del prompt o del template usato per generare il markup

Intestazioni di sezione tutte maiuscole e verbose, con commenti sullo stile eccessivamente dettagliati

Uso sistematico di trattini lunghi (em dash) e divisori a banner (====================)

Struttura a template coerente, con formattazione uniforme ma dettagli organizzativi variabili tra un’email e l’altra

In parallelo, gli attaccanti hanno anche costruito thread email interamente fittizi — conversazioni mai avvenute, presentate come inoltri — per dare l’impressione di uno scambio già in corso e abbassare la guardia del destinatario. Qui però l’AI lascia scoperture tecniche concrete: gli header di inoltro standard mancavano, il testo delle conversazioni precedenti era allineato a sinistra invece di essere formattato come citazione, e ricorrevano frasi innaturali come “no need to copy me” pensate per scoraggiare la verifica incrociata con altri colleghi.

Segnali da mettere nei playbook SOCRiassumendo gli indicatori tecnici emersi dall’#analisi, ecco cosa vale la pena monitorare attivamente:

Mismatch tra display name e indirizzo email del mittente (nome del dirigente, dominio esterno appena registrato)

Parole chiave finanziarie urgenti nell’oggetto (“due bill”, “ACH Payment”, “pagamento in sospeso”)

Header email mancanti o incoerenti in messaggi presentati come inoltri

Domini “lookalike” registrati nei giorni immediatamente precedenti l’invio massivo

Difese tecniche concreteLa prima linea di difesa resta l’autenticazione email correttamente configurata. Se il vostro dominio non ha ancora un record DMARC in modalità di enforcement, è il momento di sistemarlo:

; Esempio di record DMARC in modalità di quarantena progressiva
_dmarc.tuodominio.it. IN TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@tuodominio.it; ruf=mailto:dmarc-forensics@tuodominio.it; fo=1"

; SPF: elenca esplicitamente solo gli host autorizzati a inviare
tuodominio.it. IN TXT "v=spf1 include:spf.protection.outlook.com -all"Su Microsoft 365, oltre a SPF/DKIM/DMARC, vanno attivate le funzionalità di #Defender for Office 365 pensate proprio per questo scenario: lo Zero-hour Auto Purge (ZAP), che mette in quarantena retroattivamente i messaggi già recapitati quando emergono nuove informazioni di threat intelligence, e l’Automatic Attack Disruption, che contiene automaticamente attacchi in corso limitando l’impatto sull’organizzazione.

Per chi vuole aggiungere una regola di trasporto mirata a intercettare l’impersonificazione dei dirigenti, un buon punto di partenza in #Exchange Online #PowerShell è una regola che segnala i messaggi esterni il cui nome visualizzato coincide con quello di un dirigente interno:

New-TransportRule -Name "Flag possibile impersonificazione executive" -HeaderContainsMessageHeader "From"
-HeaderContainsWords "Mario Rossi","Giulia Bianchi" -SenderDomainIs "tuodominio.it" -ExceptIfSenderDomainIs "tuodominio.it"
-PrependSubject "[POSSIBILE IMPERSONIFICAZIONE] " `
-Mode EnforceDa ultimo, la parte umana del processo resta insostituibile: la verifica dei pagamenti ad alto valore va fatta fuori banda, ad esempio con una telefonata a un numero già noto (mai a un numero indicato nell’email stessa), e il personale amministrativo va addestrato periodicamente a riconoscere questi pattern — Microsoft mette a disposizione l’Attack Simulation Training in Defender for Office 365 proprio per esercitazioni realistiche su scenari di questo tipo.

ConclusioneQuesta campagna conferma una tendenza che i team di sicurezza dovrebbero dare ormai per acquisita: l’AI generativa non introduce necessariamente nuove tecniche di attacco, ma innalza drasticamente la qualità e la scala di quelle esistenti, rendendo la BEC “tradizionale” più difficile da distinguere da una comunicazione legittima. La buona notizia è che gli stessi strumenti di detection basati su pattern e comportamento — autenticazione email, regole di trasporto mirate, ZAP, attack disruption — restano efficaci, a patto di tenerli configurati e aggiornati. La differenza, oggi più che mai, la fa la disciplina nella configurazione, non l’ennesimo layer di prodotto.

Fonte: Microsoft Security Blog, via Petri IT Knowledgebase

Se nella vostra organizzazione l’attivazione di #Windows passa ancora da uno script che richiama slmgr.vbs, incorporato in una sequenza di task di System Center Configuration Manager, in un logon script di Active Directory o in un tool RMM, è arrivato il momento di segnarsi una scadenza in agenda. Microsoft ha confermato che il ritiro di VBScript da Windows procede secondo un piano a fasi, e ha rilasciato in parallelo un modulo #PowerShell ufficiale pensato esplicitamente per sostituire l’automazione basata su slmgr.vbs, cscript.exe e wscript.exe.

Non è un’emergenza immediata: VBScript resta disponibile oggi. Ma chi gestisce parchi macchine di centinaia o migliaia di endpoint sa bene che una migrazione di questo tipo, se rimandata all’ultimo, diventa un incendio da spegnere in corsa. Vediamo cosa cambia, quali sono le tempistiche reali e come impostare fin da ora un piano di migrazione ordinato.

Perché VBScript sta per sparireMicrosoft aveva annunciato la deprecazione di VBScript già nel 2023, come parte di una più ampia strategia di riduzione della superficie di attacco: il motore di scripting legacy è stato per anni un vettore privilegiato per #malware e tecniche di living-off-the-land, e la sua rimozione da Windows segue lo stesso percorso già intrapreso per altre componenti storiche del sistema operativo.

Il piano di ritiro si articola in tre fasi:

Fase attuale — VBScript è presente come Feature on Demand e resta abilitato per impostazione predefinita. Tutto continua a funzionare come sempre.

Fase intermedia (indicativamente dal 2027) — il componente rimarrà disponibile ma verrà disabilitato di default: le organizzazioni che ne hanno ancora bisogno dovranno riattivarlo esplicitamente tramite policy o Feature on Demand.

Fase finale — rimozione completa del motore di scripting da Windows. Microsoft non ha ancora comunicato una data precisa per questo passaggio, ma da quel momento slmgr.vbs e qualunque script dipendente da cscript/wscript smetteranno semplicemente di funzionare.

Il punto critico per i sistemisti è proprio la fase intermedia: se l’automazione di attivazione non viene aggiornata prima che VBScript venga disabilitato di default, i processi di provisioning e le immagini di deployment rischiano di rompersi silenziosamente, magari scoperti solo quando un nuovo lotto di macchine non riesce ad attivarsi.

La sostituzione ufficiale: il modulo PowerShell OSLicensePer coprire il vuoto lasciato da slmgr.vbs, Microsoft ha introdotto OSLicense, un modulo PowerShell nativo pensato per replicare — e in parte estendere — le funzioni storiche dello script VBScript. I cmdlet principali sono tre:

Attivazione online (equivalente di slmgr.vbs /ato)

Invoke-OSLicense -ActivateOnline

Installazione di una product key (equivalente di slmgr.vbs /ipk)

Invoke-OSLicense -InstallProductKey "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"

Verifica dello stato della licenza (equivalente di slmgr.vbs /dlv)

Get-OSLicenseInfoOltre a questi tre comandi base, OSLicense copre scenari enterprise più articolati: attivazione tramite KMS, attivazione basata su Active Directory (AD-based activation) e la gestione della subscription activation per i piani Windows Enterprise E3/E5. In sostanza, chiunque abbia costruito script di provisioning attorno a slmgr.vbs /skms o /ato troverà un cmdlet equivalente pronto all’uso.

Requisiti per usare OSLicense oggiIl modulo non è ancora universalmente disponibile su tutte le versioni di Windows in campo. Al momento richiede:

Windows 11: l’update opzionale KB5120998 (rilasciato il 27 agosto 2026) o successivo;

Windows Server: è disponibile a partire dalla Windows Server vNext Preview build 29651, quindi non ancora nei rami stabili di produzione.

Questo significa che, per buona parte del parco macchine server oggi in produzione, OSLicense non è un’opzione praticabile nel breve termine — un dettaglio da tenere bene a mente quando si pianifica la migrazione.

Un ponte per chi non può ancora usare OSLicensePer gli ambienti in cui Windows Script Host è già stato disabilitato per policy di sicurezza, o dove serve una soluzione utilizzabile subito senza attendere il rollout di OSLicense sui rami server, la community ha già colmato il divario. Il progetto open source slmgr-ps offre un wrapper PowerShell che replica le funzioni più usate di slmgr.vbs, con il vantaggio aggiuntivo del supporto nativo alle operazioni remote:

Informazioni sulla licenza (locale o estesa)

Get-WindowsActivation
Get-WindowsActivation -Extended
Get-WindowsActivation -Expiry

Attivazione con chiave KMS rilevata automaticamente

Start-WindowsActivation -UseKmsClientKey

Attivazione su una macchina remota

Start-WindowsActivation -Computer WS01

Reset delle impostazioni di attivazione

Reset-WindowsActivation -UninstallProductKey
Reset-WindowsActivation -ClearKMSSettingsA differenza dello script VBScript originale, che opera sempre in locale, questi cmdlet accettano array di nomi macchina: è quindi possibile lanciare un audit o una riattivazione su un intero gruppo di endpoint con un’unica riga di PowerShell, invece di iterare manualmente con psexec o sessioni #RDP.

Come impostare la migrazione senza sorpresePrima di riscrivere qualsiasi cosa, il lavoro più importante è capire dove slmgr.vbs è effettivamente referenziato nel proprio ambiente. È un’operazione che conviene affrontare in quattro passaggi:

Censire le dipendenze: cercare riferimenti a slmgr.vbs, cscript.exe e wscript.exe in task sequence MDT/SCCM, script di #Intune, GPO di logon/startup, immagini master e tool RMM di terze parti. Un semplice Select-String ricorsivo sui repository di script è un buon punto di partenza.

Classificare per urgenza: separare gli script che girano su Windows 11 con KB5120998 già installabile da quelli su Windows Server, dove OSLicense non è ancora un’opzione e serve necessariamente un ponte come slmgr-ps o una convivenza temporanea con VBScript.

Validare in un anello di test: prima di sostituire uno script di attivazione in produzione, verificarne il comportamento su un gruppo pilota di macchine, controllando in particolare gli scenari KMS e AD-based activation, storicamente i più delicati da replicare fedelmente.

Documentare e pianificare la disattivazione di VBScript: una volta che tutti gli script critici sono stati migrati, pianificare la disabilitazione esplicita del Feature on Demand VBScript sui gruppi di macchine già pronti, così da anticipare la fase di “disabled by default” invece di subirla.

ConclusioneNon c’è ancora motivo di allarmarsi, ma nemmeno di procrastinare. La finestra utile per pianificare con calma la migrazione dell’automazione di attivazione è oggi, non quando VBScript verrà disabilitato di default sui client aggiornati. Le organizzazioni con un parco Windows 11 già aggiornato possono iniziare da subito con OSLicense; chi gestisce prevalentemente Windows Server dovrà invece appoggiarsi a soluzioni ponte come slmgr-ps fino a quando il modulo ufficiale non arriverà nei rami stabili. In entrambi i casi, il primo passo resta lo stesso: sapere esattamente quanti script nel proprio ambiente dipendono ancora da un motore che, prima o poi, non ci sarà più.

Fonte: Petri.com – Windows Activation Automation Must Move Beyond VBScript, con approfondimenti dal Windows IT Pro Blog di Microsoft.

Gli aggiornamenti cumulativi di settembre 2026 per #Windows Server hanno introdotto un problema serio su Remote Desktop Services: dopo l’installazione delle #patch, le sessioni #RDP su alcuni host iniziano a bloccarsi o a rifiutare nuove connessioni, spesso dopo diverse ore di funzionamento normale. Per chi gestisce collection RDS in produzione — RDSH multi-sessione, VDI o semplicemente jump server amministrativi — è un problema da conoscere prima di distribuire la patch su larga scala, perché tocca esattamente le macchine che gli amministratori usano per raggiungere il resto dell’infrastruttura.

Quali sistemi sono coinvoltiIl problema riguarda tre cumulative update distinti, uno per versione di sistema operativo:

KB5122876 — Windows Server 2019

KB5122882 — Windows Server 2022

KB5122871 — Windows Server 2025

Le note di rilascio Microsoft segnalano separatamente anche problemi su Windows Server 2016, con la redirezione audio di Remote Desktop non funzionante dopo l’installazione. Va inoltre ricordato che il pacchetto di settembre non è “solo” quello che introduce il bug: nello stesso ciclo Microsoft ha corretto oltre 970 vulnerabilità, incluse due zero-day già sfruttate attivamente. Questo rende la scelta “disinstallo la patch” tutt’altro che indolore.

Sintomi osservatiDalle segnalazioni raccolte dagli amministratori nei forum tecnici e da chi ha già debuggato il problema, il pattern tipico è il seguente:

RDS funziona normalmente per diverse ore dopo il riavvio post-patch;

le sessioni RDP esistenti smettono di disconnettersi o effettuare il logoff correttamente;

i nuovi tentativi di connessione restano bloccati sulla schermata “Connecting…” fino a fallire;

in alcuni casi il servizio va in crash dopo il primo logout utente, impedendo login successivi;

Task Manager e le impostazioni di sistema diventano a loro volta non responsive sull’host colpito, rendendo necessario un hard reset.

Chi ha fatto debugging più approfondito ha individuato nei log un deadlock nella libreria server RDP durante la chiusura di sessione: l’evento si blocca nella routine RDPSERVERBASE!WDLIB_Close, apparentemente senza timeout configurato, generando uno stallo tra il processo RDP e LSM (Local Session Manager). Nei log di sistema il sintomo si traduce nell’evento 20498 nel canale Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin.

Come verificare se un host è colpitoPrima di intervenire, è utile raccogliere qualche riscontro diagnostico in sola lettura:

Verifica eventi di timeout sulla connessione RDP

Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
Id = 20498
} -MaxEvents 5 | Format-Table TimeCreated, Message -Wrap

Controlla lo stato del servizio Terminal Services

Get-Service -Name TermService | Select-Object Name, StatusSe l'evento 20498 compare in concomitanza con logoff o riconnessioni di sessione, l'host è verosimilmente esposto al bug.

Le opzioni sul tavoloAl momento della stesura di questo articolo Microsoft non ha ancora confermato pubblicamente la causa né rilasciato una patch out-of-band; l'azienda ha dichiarato di essere a conoscenza delle segnalazioni e di stare indagando. Questo lascia agli amministratori due strade principali, entrambe con compromessi da valutare con attenzione:

1. Rollback del pacchetto cumulativoÈ l'opzione più testata e documentata. Rimuove il bug ma riporta l'host allo stato di vulnerabilità precedente, comprese le due zero-day corrette a settembre — accettabile solo come misura temporanea su host isolati o con mitigazioni compensative (segmentazione di rete, restrizioni di accesso RDP tramite VPN/Bastion) già in campo.

Individua il pacchetto della cumulative update installata

dism.exe /Online /Get-Packages /Format:Table | findstr /i "Package_for_RollupFix"

Rimuove il pacchetto (sostituire con il nome esatto restituito sopra)

dism.exe /Online /Remove-Package /PackageName:Package_for_RollupFix31bf3856ad364e35amd64~~20348.5622.1.2 /NoRestart

Riavvio richiesto per applicare la modifica

Restart-Computer -ForceSu una collection RDS gestita, conviene prima spostare l'host fuori rotazione per evitare che riceva nuove connessioni durante l'intervento:

Import-Module RemoteDesktop
Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed No

... rollback e riavvio ...

Set-RDSessionHost -CollectionName "NomeCollection" -SessionHost "host.dominio.local" -NewConnectionAllowed Yes2. Workaround alternativi circolati in communityAlcuni blog tecnici indipendenti propongono un override tramite feature flag in HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides, con l'obiettivo di disattivare selettivamente il componente incriminato senza rimuovere l'intera patch di sicurezza. Va detto con chiarezza: si tratta di un workaround non ufficiale, non validato da Microsoft, che tocca un'area del registro sensibile e non documentata pubblicamente per questo scopo. Non è consigliabile applicarlo direttamente in produzione: se lo si vuole testare, farlo solo su un host di laboratorio isolato, con backup del ramo di registro prima e dopo, e senza aspettarsi supporto ufficiale in caso di problemi.

Cosa fare adessoIl consiglio più solido, in attesa di una risposta ufficiale Microsoft, resta quello suggerito dai team di sicurezza che seguono il caso: distribuire l'aggiornamento di settembre prima su un piccolo gruppo di host RDS non critici, monitorare l'evento 20498 e lo stato del servizio TermService per 24-48 ore, e mantenere pronto un piano di rollback per gli host di produzione più esposti. Vale anche la pena avvisare in anticipo chi gestisce l'help desk: sessioni RDP che si bloccano "a caso" dopo qualche ora sono un sintomo facile da scambiare per un problema di rete o di carico, mentre qui l'origine è chiaramente lato patch.

Fonte: 4sysops – September Windows Server updates break Remote Desktop Services (RDS); approfondimenti tecnici da BleepingComputer e Cyber Security News.

Il problema del “connector sprawl” nei SOC multi-tenantChi gestisce un SOC (Security Operations Center) per un’organizzazione di dimensioni medio-grandi conosce bene un problema che raramente compare nelle demo dei prodotti #SIEM: le aziende moderne non vivono con un solo account per servizio. Un gruppo con più business unit può avere diversi tenant Auth0 segmentati per prodotto, più ambienti CrowdStrike Falcon per effetto di fusioni e acquisizioni, o più organizzazioni Salesforce distinte per area geografica o #normativa.

Fino a oggi, portare tutta questa telemetria dentro un’unica workspace Microsoft #Sentinel significava scontrarsi con un limite architetturale del modello dei connector: un connector, un account. Il risultato erano configurazioni duplicate, script custom per aggregare i dati, o — nello scenario peggiore — interi ambienti lasciati fuori dal perimetro di monitoraggio per semplice sovraccarico operativo. Microsoft ha ora affrontato direttamente questo problema con il supporto multi-account per tre connector molto usati in ambito enterprise.

Cosa cambia: supporto multi-account per Auth0, CrowdStrike Falcon e SalesforceCon l’aggiornamento annunciato sul Microsoft Sentinel Blog, i data connector per Auth0, CrowdStrike Falcon e Salesforce Service #Cloud supportano ora l’ingestione da più account o tenant attraverso un’unica configurazione di connector. La funzionalità si appoggia al Codeless Connector Framework (CCF), il framework che Microsoft utilizza per costruire connector dichiarativi senza dover scrivere codice custom per ogni integrazione.

Nello specifico, per ciascuna delle tre piattaforme cambia questo:

Auth0 — Multi-Tenant Identity Monitoring: i team che gestiscono più tenant Auth0 possono ora far confluire eventi di autenticazione, pattern di login anomali e violazioni di policy da tutti i tenant in un’unica workspace Sentinel, senza dover cambiare contesto per ogni ambiente.

CrowdStrike Falcon — Telemetria endpoint consolidata: le organizzazioni con più tenant Falcon (tipicamente per effetto di M&A o strutture regionali separate) possono ora far confluire detection alert, threat intelligence ed endpoint telemetry da tutti i tenant in un’unica pipeline di ingestione.

Salesforce Service Cloud — Insight cross-org: le aziende con più organizzazioni Salesforce possono centralizzare audit log, cronologia dei login e attività API su tutte le org, semplificando il rilevamento di insider threat, accessi non autorizzati e gap di #compliance senza dover correlare manualmente dati provenienti da fonti separate.

Come funziona in pratica: il workflow “Add Account”Il punto di forza dell’implementazione è la sua semplicità operativa. Non serve distribuire una nuova istanza del connector per ogni account: il connector esistente espone un nuovo comando che permette di aggiungere account aggiuntivi alla stessa configurazione. Il flusso, come descritto da Microsoft, si riduce a pochi passaggi:

Aprire Microsoft Sentinel → Data Connectors nel portale #Azure.

Cercare il connector desiderato (Auth0, CrowdStrike Falcon o Salesforce).

Aprire il connector e selezionare l’opzione “Add Account”.

Autenticare e autorizzare l’account aggiuntivo (tramite le credenziali/API key specifiche della piattaforma).

Avviare l’ingestione: i dati del nuovo account confluiscono automaticamente nella stessa tabella di log della workspace.

Un dettaglio operativo rilevante per chi già gestisce regole di detection in produzione: le analytics rule, i workbook e i playbook esistenti continuano a funzionare senza modifiche, perché operano sullo stesso schema di dati indipendentemente dal numero di account collegati. Non è quindi necessario duplicare le regole di correlazione per ogni tenant aggiunto: una singola query KQL scritta per rilevare, ad esempio, tentativi di login falliti ripetuti su Auth0 continuerà a funzionare — e a coprire — tutti i tenant collegati al connector, con la possibilità di filtrare o raggruppare per account direttamente nella query se serve un’#analisi granulare.

Perché conta per chi gestisce un SOCAl di là dell’annuncio, il valore pratico di questa funzionalità si misura su tre assi che chiunque abbia gestito un ambiente Sentinel multi-tenant riconoscerà:

Riduzione del carico di configurazione. Ogni connector duplicato è una configurazione da mantenere, da tenere sotto controllo per la scadenza delle credenziali, da documentare separatamente. Consolidare in un’unica configurazione riduce direttamente il lavoro di manutenzione ricorrente.

Eliminazione dei blind spot. È comune che un ambiente “secondario” (un tenant acquisito di recente, una org regionale minore) resti fuori dal monitoraggio semplicemente perché configurarlo separatamente non è mai stata la priorità. Abbassare la barriera operativa per aggiungere un account rende più probabile che venga effettivamente monitorato.

Indagini cross-environment più semplici. Durante un incident response, poter interrogare un’unica tabella per correlare eventi provenienti da più tenant/org, invece di dover incrociare manualmente dati da workspace o strumenti diversi, accorcia sensibilmente il tempo di analisi.

Cosa considerare prima di attivarloQualche aspetto pratico da valutare prima del rollout in un ambiente esistente:

Volume di ingestione e costi. Consolidare più account nello stesso connector aumenta il volume di dati ingeriti nella workspace Sentinel: vale la pena rivedere le stime di costo (Sentinel fattura in base al volume di dati analizzato/ingerito) prima di collegare tutti gli account contemporaneamente.

Permessi e segregazione. Se la governance interna richiede una separazione netta tra i dati di sicurezza di business unit diverse (ad esempio per requisiti normativi regionali), verificate come vengono gestiti i controlli di accesso a livello di query/workbook nella workspace condivisa, dato che i dati di più account convivono nelle stesse tabelle.

Compatibilità delle credenziali API. Ogni account aggiunto richiede la propria autenticazione verso la piattaforma di origine (API key Auth0, credenziali API CrowdStrike, connected app Salesforce): pianificate la rotazione delle credenziali per ciascun account separatamente.

Microsoft indica inoltre che il supporto multi-account continuerà a essere esteso ad altri connector nei prossimi rilasci, segno che il modello “un connector, molti account” diventerà probabilmente lo standard per le integrazioni costruite sul Codeless Connector Framework, non un’eccezione limitata a queste tre piattaforme.

ConclusionePer i team che gestiscono Microsoft Sentinel su ambienti articolati — gruppi con più società, aziende cresciute per acquisizioni, organizzazioni con presenza multi-regionale — questo aggiornamento rimuove uno degli attriti operativi più concreti nella gestione quotidiana del SIEM. Vale la pena rivedere oggi stesso la configurazione dei connector Auth0, CrowdStrike Falcon e Salesforce già in uso, capire quanti account “orfani” non sono ancora monitorati per pura complessità di setup, e valutare la migrazione verso la configurazione multi-account, tenendo d’occhio l’impatto sul volume di ingestione prima di collegare tutto in blocco.

Fonte: Microsoft Security Community Blog.

Con l’adozione di #Copilot che accelera dentro Microsoft 365, molti team IT si stanno scontrando con un problema che precede di anni l’AI generativa ma che l’AI generativa rende improvvisamente urgente: la sovraesposizione dei dati. File condivisi “a chiunque abbia il link” dimenticati su #SharePoint anni fa, permessi ereditati mai ripuliti, cartelle OneDrive con dati finanziari accessibili a interi reparti. Finché a leggere quei file era un motore di ricerca aziendale poco usato, il rischio restava contenuto. Con un assistente AI che risponde a qualunque domanda pescando da tutto ciò a cui l’utente ha accesso, ogni permesso mal configurato diventa una potenziale fuga di informazioni istantanea. Microsoft #Purview Data Security Posture Management (DSPM) nasce per rispondere proprio a questo scenario, e vale la pena capire cosa fa concretamente, prima di attivare Copilot su larga scala.

Cos’è DSPM e perché non è “un altro tool di compliance”DSPM è il componente di Microsoft Purview dedicato a rispondere a quattro domande fondamentali sulla postura di sicurezza dei dati di un’organizzazione:

Che dati abbiamo? — discovery e classificazione automatica

Dove sono conservati? — mappatura di location e storage

Chi può accedervi? — #analisi dei pattern di accesso e permessi

Come sono protetti? — valutazione delle policy di protezione applicate

A differenza di un tool di #compliance tradizionale che verifica la conformità a una #normativa in un dato momento, DSPM è pensato per essere continuo: monitora costantemente lo stato dei dati sensibili in Microsoft 365, #Azure e alcune piattaforme di terze parti, e traccia se l’esposizione migliora o peggiora nel tempo attraverso un grafico di trend a 30 giorni sulla dashboard principale.

Il flusso operativo: discovery, assessment, remediationDSPM lavora attraverso cinque fasi concettuali:

Discovery: individua informazioni sensibili — dati di payroll, codici fiscali, contratti, proprietà intellettuale, codice sorgente — usando classificatori integrati e sensitive information type basati su pattern matching (numeri di carte di credito, patenti, SSN, oltre a classificazioni personalizzate per record finanziari o contratti specifici dell’organizzazione)

Assessment: valuta lo stato di crittografia, l’applicazione di etichette di sensibilità e i rischi di condivisione eccessiva

Prioritizzazione: ordina i problemi rilevati per severità, in modo da affrontare prima gli elementi a rischio più alto

Remediation: applica azioni correttive — etichette di sensibilità, riduzione dei permessi, creazione di policy DLP

Monitoraggio continuo: verifica se l’esposizione dei dati migliora o peggiora nel tempo

Un punto tecnico che vale la pena chiarire subito, perché genera spesso confusione: DSPM individua l’esposizione, DLP la applica. DSPM è lo strumento di ricerca e scoperta — risponde a “dove abbiamo un problema” — mentre Data Loss Prevention è il livello che impone effettivamente restrizioni comportamentali una volta identificato il rischio. Non sono strumenti alternativi ma complementari, e DSPM può generare direttamente raccomandazioni per creare o affinare policy DLP.

Le funzionalità chiaveData risk assessmentDSPM offre assessment predefiniti e personalizzabili che identificano contenuti sovraesposti, protezione inadeguata, etichette di sensibilità mancanti e permessi ad alto rischio. Quando questi problemi vengono confermati, DSPM può automatizzare passaggi di remediation come la rimozione di link di condivisione pubblici, l’applicazione di policy DLP, la revoca di permessi o l’applicazione di etichette di sensibilità — prima che l’incidente si verifichi, non dopo.

Rilevamento dei percorsi di esfiltrazioneUno degli use case più concreti è la mappatura dei cosiddetti “exfiltration path”: dati sensibili condivisi esternamente, o informazioni business-critical protette da controlli di accesso deboli. DSPM consolida in questo ambito gli insight provenienti da quattro soluzioni Purview distinte: Data Loss Prevention, Insider Risk Management, Information Protection (etichette di sensibilità) e Data Security Investigations — offrendo così una vista unificata invece di quattro dashboard scollegate.

DSPM for AI: la componente più rilevante per chi sta adottando CopilotCon l’estensione DSPM for AI, Microsoft ha aggiunto un livello di osservabilità specifico per gli agenti e le app AI, incluso Microsoft Agent 365. L’AI Observability Dashboard fornisce:

Un inventario delle app e degli agenti AI in uso nell’organizzazione

Attività registrata negli ultimi 30 giorni

Il conteggio degli agenti considerati ad alto rischio

Il numero totale di agenti che interagiscono con dati sensibili

Una vista dettagliata per singolo agente e per policy di governance applicata

In pratica, prima di dare a Copilot (o a qualunque altro agente AI collegato al tenant) accesso ai dati aziendali, DSPM for AI permette di vedere quali repository quell’agente toccherebbe e con quale livello di rischio, invece di scoprirlo a posteriori tramite un incidente.

Attivazione: i setup task principaliLa configurazione iniziale avviene dal Microsoft Purview portal, sotto DSPM > Actions > Setup tasks, dove ogni attività include istruzioni passo-passo, stato di completamento, tempo stimato e impatto previsto sugli utenti. I task principali sono:

Setup taskCosa faNoteAttivazione Microsoft Purview AuditVerifica che l’audit sia abilitatoAttivo di default sui tenant nuovi, va abilitato manualmente sui tenant esistentiOnboarding dei dispositiviDeploy su endpoint WindowsNecessario per la visibilità su siti AI di terze parti e per endpoint DLPEstensione browser PurviewDeploy su Chrome/EdgeRichiesta per le policy DLP a livello di browserEtichette di sensibilitàCrea etichette e policy predefiniteSolo se non già configurate nel tenantConfigurazione billingAttiva il pay-as-you-goRichiesta per alcune configurazioni avanzateIntegrazione con SentinelCollega il content hubFunzionalità in previewUn aspetto da verificare con attenzione prima del rollout è quello dei permessi: la documentazione ufficiale non elenca in modo esplicito i ruoli richiesti (Global Admin, Security Admin, Compliance Admin), quindi è opportuno validare con un tenant di test quali ruoli minimi servono per ciascun setup task, prima di assegnare permessi troppo ampi al team che gestirà DSPM in produzione.

Licensing: cosa aspettarsiDSPM (in versione “classica”) è incluso nelle licenze Microsoft 365 E5 / E5 Compliance, mentre alcune funzionalità più avanzate — in particolare componenti di DSPM for AI e alcune configurazioni di billing pay-as-you-go — possono richiedere add-on o un modello di consumo separato. Prima di pianificare il rollout, vale la pena verificare la Microsoft Purview Licensing Guidance aggiornata, perché il pacchetto di funzionalità incluse per fascia di licenza è soggetto a modifiche frequenti.

DSPM non sostituisce la compliance tradizionaleUn’ultima precisazione utile per chi deve giustificare il progetto internamente: DSPM offre visibilità sul trattamento dei dati sensibili ed è un complemento prezioso agli strumenti di compliance tradizionali, ma non li sostituisce. Framework normativi (GDPR, ISO 27001, settoriali) richiedono comunque processi, documentazione e controlli dedicati. DSPM riduce il rischio operativo e dà visibilità continua, ma resta uno strumento di data security posture, non un motore di conformità normativa.

Quando ha senso adottarloDSPM è particolarmente utile per organizzazioni che:

Stanno pianificando o hanno già distribuito Copilot su larga scala

Gestiscono ambienti SharePoint/OneDrive di grandi dimensioni con anni di condivisioni stratificate

Trattano dati regolamentati (finanziari, sanitari, PII in generale)

Faticano a mantenere visibilità sulla governance dei dati a scala aziendale

Organizzazioni piccole, con esigenze di compliance minime e un perimetro dati contenuto, potrebbero non trarne un beneficio proporzionato al costo di licenza e all’impegno di configurazione iniziale.

ConclusioneIl messaggio di fondo di DSPM è semplice ma spesso trascurato: attivare Copilot senza prima aver mappato chi può accedere a cosa significa dare a un assistente AI estremamente efficiente nel trovare informazioni lo stesso identico perimetro di accesso — sbagliato — che esisteva già, solo molto più velocemente interrogabile. Per i team che gestiscono tenant Microsoft 365 di dimensioni medio-grandi, un ciclo di discovery e remediation con DSPM prima del rollout di Copilot non è un passaggio opzionale di “nice to have”, ma la differenza tra un’adozione AI controllata e un incidente di esposizione dati che si scopre solo dopo che è già successo.

Fonte originale: Microsoft Purview Data Security Posture Management Explained: How It Reduces Data Exposure Before Copilot – Petri IT Knowledgebase (Brien Posey). Approfondimenti tecnici da Microsoft Learn.

Una catena di due CVE trasforma SharePoint in un bersaglio non autenticatoAd agosto 2026 Rapid7 e VulnCheck hanno pubblicato, in tempi ravvicinati, l’#analisi tecnica di una catena di exploit che colpisce Microsoft #SharePoint Server on-premises con impatto massimo: esecuzione di codice remoto senza alcuna autenticazione. La catena combina due vulnerabilità distinte, #CVE-2026-55040 (bypass di autenticazione JWT, CVSS 9.1) e CVE-2026-63520 (istanziazione insicura di tipi .NET nel motore Business Data Connectivity), e secondo Shadowserver oltre 8.700 server SharePoint risultano ancora esposti direttamente su #Internet. Per chi gestisce infrastrutture SharePoint on-prem non si tratta di un bollettino da archiviare: è una delle catene di attacco più pericolose viste sulla piattaforma dai tempi di ToolShell.

CVE-2026-55040: quando il token JWT non prova più nullaIl primo anello della catena riguarda la pipeline di validazione dei token JWT usati internamente da SharePoint per l’autenticazione tra servizi. A causa di controlli insufficienti su questi token, un attaccante che conosca in anticipo l’identità di un utente target (tramite il suo SID di Active Directory o il suo UPN, entrambi spesso enumerabili o prevedibili in ambienti aziendali) può forgiare un token valido e impersonarlo senza fornire alcuna credenziale. Il risultato è un bypass completo dell’autenticazione: l’attaccante #entra nel sistema con l’identità di un utente legittimo, potenzialmente un amministratore.

Da sola, questa vulnerabilità (classificata CWE-1390, “Weak Authentication”) sarebbe già critica. Ma è il punto di ingresso che rende possibile il secondo, ben più devastante, stadio della catena.

CVE-2026-63520: RCE tramite Business Data ConnectivityIl secondo CVE affligge il sottosistema Business Data Connectivity (BDC) di SharePoint, che permette di collegare fonti dati esterne tramite modelli descritti in file XML con estensione .bdcm. La causa radice è un’istanziazione di tipi .NET non sufficientemente validata nella classe DbTypeReflector: il metodo ResolveDotNetType() chiama direttamente Type.GetType() su un valore TypeName controllato dall’attaccante, senza un controllo efficace. Il filtro di sicurezza esistente si limitava a bloccare nomi di tipo corti, ma nomi di tipo superiori ai 15 caratteri bypassavano il controllo, aprendo la porta a qualunque tipo .NET disponibile nella Global Assembly Cache (GAC).

In pratica, un attaccante autenticato (o, dopo il bypass JWT, di fatto chiunque) può caricare un file BDCM appositamente costruito che definisce un LobSystem, un’Entity e un MethodInstance di tipo Finder. Quando SharePoint valuta una External List collegata a quel modello, il Finder viene eseguito automaticamente. I ricercatori hanno dimostrato più catene di gadget funzionanti, tra cui una basata su System.Windows.Data.ObjectDataProvider combinato con System.Diagnostics.Process per l’esecuzione diretta di comandi, e una variante che sfrutta System.Web.UI.LosFormatter.Deserialize() con un gadget TypeConfuseDelegate codificato in Base64 per innescare la deserializzazione insicura. Un semplice payload di prova può lanciare calc.exe sul server con i privilegi dell’account di servizio di SharePoint; in produzione, lo stesso meccanismo consente l’esecuzione di codice arbitrario, inclusi payload di post-exploitation completi.

La catena completa: da zero credenziali a RCEConcatenando le due vulnerabilità, un attaccante che conosce solo lo UPN o il SID di un account SharePoint può:

Forgiare un token JWT valido sfruttando CVE-2026-55040, ottenendo un contesto di autenticazione senza credenziali reali;

Usare quel contesto per caricare un modello BDC malevolo e sfruttare CVE-2026-63520;

Ottenere esecuzione di codice remoto con i privilegi dell’account applicativo di SharePoint, tipicamente con accesso ampio al farm e, a cascata, ad Active Directory.

È esattamente questo l’aspetto che ha spinto VulnCheck a pubblicare i dettagli tecnici in anticipo rispetto all’embargo standard di 30 giorni: un PoC pubblico era già in circolazione e la finestra di rischio per i server non patchati si stava riducendo rapidamente. Bleeping Computer e SecurityAffairs hanno successivamente confermato tentativi di sfruttamento attivo in the wild, mentre la società di threat intelligence Defused ha osservato attività di ricognizione sistematica contro honeypot SharePoint esposti.

Versioni affette e patch disponibiliMicrosoft ha rilasciato aggiornamenti dedicati per tutte le edizioni supportate on-premises:

SharePoint Server Subscription Edition: KB5002882, build 16.0.19725.20434

SharePoint Server 2019: KB5002883, build 16.0.10417.20175

SharePoint Enterprise Server 2016: KB5002891, build 16.0.5561.1001

SharePoint Online (Microsoft 365) non è interessato: il rischio riguarda esclusivamente le installazioni on-premises. Se gestite un farm SharePoint self-hosted, la priorità è applicare queste patch ora, non nella prossima finestra di manutenzione pianificata.

Cosa fare subito, in praticaOltre al patching, che resta la contromisura primaria e non negoziabile, alcune azioni concrete per ridurre l’esposizione e rilevare eventuali compromissioni:

Inventariare i server esposti: verificate quali istanze SharePoint sono raggiungibili direttamente da Internet e valutate se sia davvero necessario, oppure se possano essere posizionate dietro un reverse proxy con autenticazione aggiuntiva o una VPN.

Controllare la build corrente: dalla Central Administration o via PowerShell (Get-SPFarm | Select BuildVersion) verificate che i server siano allineati alle build patchate elencate sopra.

Monitorare i log IIS e ULS per pattern di autenticazione anomali (token JWT sospetti, accessi con identità che normalmente non generano traffico da quell’origine) e per upload o modifiche di modelli BDC non pianificati.

Verificare le configurazioni Business Connectivity Services: se il farm non usa BDC/BCS in modo attivo, valutate se disabilitare il servizio riduce la superficie d’attacco senza impatti operativi.

Applicare il principio del minimo privilegio agli account di servizio di SharePoint, così da limitare il “raggio d’azione” di un’eventuale esecuzione di codice riuscita.

La combinazione di autenticazione bypassabile e deserializzazione insicura è un pattern che SharePoint ha già visto in passato (basti pensare a ToolShell nel 2025), e che continua a ripresentarsi perché il BDC/BCS resta un componente ricco di superficie d’attacco poco monitorato rispetto ad altre parti della piattaforma. Vale la pena, in generale, trattare ogni funzionalità di connettività dati esterna come un potenziale vettore di deserializzazione e sottoporla a hardening a prescindere dal CVE del momento.

Fonte originale: Petri IT Knowledgebase – SharePoint Exploit Code Puts Thousands of Internet-Facing Servers At Risk. Analisi tecnica aggiuntiva: Rapid7 su CVE-2026-55040, Rapid7 su CVE-2026-63520 e VulnCheck.

Per anni la community .NET ha guardato con una certa invidia i colleghi che sviluppano su Avalonia UI o Uno Platform: framework UI nativi per #Windows, ma con il codice sorgente completamente aperto e contribuibile da chiunque. WinUI, il toolkit di interfaccia moderno di Microsoft per applicazioni desktop Windows, è invece rimasto per anni uno sviluppo “a porte chiuse”, con un repository pubblico più che altro simbolico e la vera attività di sviluppo confinata ad #Azure #DevOps interno. Questo sta cambiando, ma con una tabella di marcia più articolata di quanto il titolo delle notizie di questi giorni lasci intendere.

Cos’è WinUI e perché la sua apertura contaWinUI 3 è il motore di rendering e la libreria di controlli su cui si basa il Windows App SDK, l’evoluzione moderna dello stack UI di Windows che ha sostituito (o affiancato, a seconda dei casi) UWP, WPF e Windows Forms per le applicazioni desktop native più recenti. È il framework consigliato da Microsoft per chi scrive nuove applicazioni Windows in C#/.NET con un’interfaccia utente moderna, fluida e coerente con il design system di Windows 11.

Il problema storico è che, pur essendo distribuito come pacchetto NuGet open source, lo sviluppo effettivo del codice avveniva internamente. Il repository #GitHub microsoft/microsoft-ui-xaml serviva principalmente per il tracciamento delle issue, non per contributi di codice reali. Questo ha generato negli anni frustrazione attorno a problemi noti e mai risolti: supporto incompleto per i valori decimali nel controllo NumberBox, finestre di dialogo modali poco affidabili, gap nella validazione degli input, l’assenza di un designer visuale integrato in Visual Studio e prestazioni non sempre all’altezza rispetto alla vecchia UWP.

Il piano a quattro fasiMicrosoft ha pubblicato la roadmap dell’apertura in una discussion ufficiale sul repository, ed è organizzata in quattro fasi progressive, non in un singolo “flip the switch”:

Fase 1 (completata, ott. 2025)
→ aumento della frequenza di mirroring da Azure DevOps a GitHub:
i commit interni diventano visibili quasi in tempo reale

Fase 2 (completata, dic. 2025)
→ gli sviluppatori esterni possono clonare il repository e
compilarlo in locale, con documentazione sulle dipendenze

Fase 3 (completata, mag. 2026)
→ i contributor possono aprire pull request (mirrorate
internamente) ed eseguire la test suite in locale;
il team ha districato le dipendenze private e reso
pubblica l'infrastruttura di test

Fase 4 (in corso, target set. 2026)
→ GitHub diventa l'hub di sviluppo primario, eliminando
il mirroring interno come centro di gravità del progetto
Ad oggi ci troviamo quindi tra la fase 3 e la fase 4: il codice è realmente visibile e buildabile, ma il flusso di contribuzione della community non è ancora quello “GitHub-native” a cui si è abituati con altri progetti open source Microsoft come .NET stesso o VS Code.

Cosa si può fare concretamente oggiPer chi vuole già mettere le mani sul codice, i requisiti pratici per compilare WinUI in locale sono non banali: circa 80 GB di #spazio disco libero e almeno 32 GB di RAM per una build confermata funzionante. Non è un progetto leggero da compilare su un #laptop di fascia media.

git clone https://github.com/microsoft/microsoft-ui-xaml.git
cd microsoft-ui-xaml

seguire la documentazione del repository per le

dipendenze del toolchain e i target di build supportati

Il branch principale (winui3/main) riceve tuttora sincronizzazioni dirette da Azure DevOps, quindi è aggiornato ma non ancora il punto di partenza esclusivo dello sviluppo. La test suite è ora eseguibile pubblicamente, il che permette di verificare in autonomia se una patch personalizzata introduce regressioni prima di proporla come contributo.

Cosa resta chiuso, e perchéNon tutto lo stack diventerà pubblico nel breve termine. WinUI ha “radici profonde” in componenti proprietari del sistema operativo, e alcune aree restano fuori dal perimetro di apertura, almeno per ora:

Il compilatore XAML: è il focus dichiarato della fase 4, ma resta per ora un componente interno.

La compilazione dei pacchetti MSIX: strettamente legata alla toolchain di packaging di Windows.

Alcuni layer di gestione input: in particolare Microsoft.UI.Input.dll è indicato esplicitamente come area problematica da aprire, per via delle dipendenze con sottosistemi Windows non pubblici.

Beth Pan, una delle maintainer del progetto, ha descritto il processo con una frase che vale la pena riportare: non è “un interruttore da girare”, ma un percorso deliberato. È un’aspettativa realistica da tenere a mente prima di proporre la prima pull request pensando di vederla mergeata in tempi brevi.

Come si posiziona rispetto alle alternativePer chi sta scegliendo oggi un framework UI desktop per .NET, un confronto rapido aiuta a inquadrare la novità:

WinUI 3 / Windows App SDK: nativo Windows, massima integrazione col design system Windows 11, ora in fase di apertura ma sviluppo ancora a trazione Microsoft; solo Windows.

Avalonia UI: completamente open source da anni, cross-platform (Windows, Linux, macOS), community di contributor esterni consolidata, look and feel personalizzabile via XAML-like styling.

Uno Platform: nato come porting di UWP/WinUI verso altre piattaforme (inclusi WebAssembly e mobile), open source, spesso scelto proprio da chi vuole la sintassi WinUI ma con vera portabilità multipiattaforma.

.NET MAUI: soluzione ufficiale Microsoft per mobile e desktop cross-platform, con un modello a controlli nativi per piattaforma anziché un motore di rendering condiviso come Avalonia.

L’apertura di WinUI non cambia immediatamente questo quadro competitivo, ma riduce un differenziale reale: la trasparenza sullo sviluppo. Poter vedere le pull request in corso, le decisioni di design discusse pubblicamente e i problemi di performance affrontati in tempo reale è un beneficio concreto anche per chi non contribuirà mai una riga di codice, perché permette di valutare con più cognizione di causa se e quando un problema noto (penso al supporto NumberBox o alla stabilità dei dialoghi modali) verrà effettivamente risolto.

ConclusioneChi sviluppa applicazioni desktop Windows in .NET dovrebbe iniziare a seguire da vicino il repository microsoft/microsoft-ui-xaml, non tanto per proporre subito una pull request quanto per avere finalmente visibilità reale sulla roadmap tecnica del framework che probabilmente sta già usando in produzione. La fase 4, attesa per settembre 2026, sarà il vero banco di prova: se GitHub diventerà davvero il centro di sviluppo primario, WinUI potrà iniziare a colmare il gap di fiducia accumulato in anni di sviluppo chiuso rispetto a progetti come Avalonia. Fino ad allora, vale la pena testare la build locale e valutare in autonomia lo stato di salute del progetto, invece di affidarsi solo agli annunci ufficiali.

Fonte: 4sysops.com. Dettagli tecnici sulla roadmap: GitHub Discussion #10700. Documentazione ufficiale: Microsoft Learn — WinUI 3.

RE: https://floss.social/@Luanti/117169073342773205

🚨 Altro abuso di Google Play.

Su segnalazione di Microsoft, è stato rimosso da Google Play Luanti, un progetto open source che offre un’alternativa libera a Minecraft.

Ancora una volta, un progetto open source viene messo fuori gioco attraverso una piattaforma centralizzata, sulla base di una segnalazione di una Big Tech.

Abbiamo ripubblicato la notizia nel gruppo @giochi@diggita.com.

#Luanti #GooglePlay #OpenSource #Microsoft #SoftwareLibero #BigTech

Microsoft starebbe lavorando a una nuova funzione di Link to Windows, l’app che collega smartphone Android e PC Windows, capace di andare ben oltre il semplice blocco remoto attualmente disponibile. Secondo quanto emerso dall’analisi del codice dell’app Android, in futuro potrebbe essere possibile spegnere, riavviare o mettere in sospensione un PC Windows 11 direttamente dallo smartphone, anche a distanza.

Il PC si comanda dallo smartphoneLa scoperta arriva dall’analisi dell’app Link to Windows per Android, all’interno della quale sono stati individuati riferimenti a comandi per il riavvio, la sospensione e lo spegnimento del computer collegato. Non solo: sembra che siano previste anche le opzioni “aggiorna e riavvia” e “aggiorna e spegni”, pensate per completare l’installazione degli aggiornamenti di Windows Update direttamente dal telefono. Attualmente Link to Windows permette solo di bloccare il PC connesso: la nuova funzione estenderebbe questa possibilità fino al controllo completo dello stato di alimentazione, tornando utile ad esempio se si dimentica il computer acceso uscendo di casa, oppure se si desidera riavviarlo da remoto prima di rientrare.

Avvisi per evitare perdite di datiTrattandosi di operazioni potenzialmente rischiose per il lavoro non salvato, Microsoft avrebbe previsto una serie di avvisi di sicurezza. Scegliendo di spegnere o riavviare il PC, l’utente riceverebbe una notifica che segnala il possibile rischio di perdere documenti non salvati, dato che da remoto non è possibile verificarne lo stato. Anche durante l’installazione di un aggiornamento di sistema comparirebbe un avviso dedicato, mentre la messa in sospensione interromperebbe temporaneamente la connessione con Phone Link, richiedendo un intervento manuale sul PC per riattivarla.

Un’integrazione Android-Windows sempre più strettaNegli ultimi mesi Microsoft ha ampliato più volte le funzioni di collegamento tra Windows 11 e i dispositivi Android, dalla gestione dei messaggi alla condivisione di file e notifiche. Con questa novità, lo smartphone Android potrebbe trasformarsi sempre di più in un vero e proprio telecomando per il PC, oltre il semplice hub di notifiche. Va detto che la funzione, al momento, non risulta ancora attiva lato server: non è quindi garantito che venga rilasciata così com’è stata trovata nel codice. Se confermata, però, si tratterebbe di un’aggiunta molto pratica per chi utilizza entrambi gli ecosistemi quotidianamente.

Negli ultimi mesi molti team hanno scoperto a proprie spese che il problema più grande di un agente AI in produzione non è la qualità del prompt, ma la sua affidabilità operativa. Un articolo recente su DZone, “Your AI Agent Is a Distributed System, Not a Chatbot”, mette a fuoco un punto che chi progetta sistemi backend conosce bene da anni: se un componente deve sopravvivere a crash, timeout, retry e attese umane di ore, non puoi trattarlo come una semplice chiamata sincrona a un modello. Devi trattarlo come un sistema distribuito, con tutto ciò che questo comporta: stato persistente, checkpoint, idempotenza e recovery.

In questo articolo riprendiamo quei concetti e li caliamo nella pratica con .NET, mostrando come Azure Durable Functions (o alternative come Temporal) permettano di costruire agenti AI multi-step che non perdono lo stato quando qualcosa va storto — cosa che, in produzione, prima o poi succede sempre.

Perché un chatbot stateless non bastaUn chatbot classico è un ciclo request/response: l’utente scrive, il modello risponde, fine. Un agente AI enterprise, invece, tipicamente deve:

orchestrare più chiamate a modelli e strumenti in sequenza o in parallelo;

interrogare sistemi esterni (CRM, ticketing, knowledge base, database);

attendere l’approvazione di un umano, che può richiedere minuti oppure ore;

gestire fallimenti parziali senza dover ripartire da zero;

garantire che un’azione con effetti collaterali (un rimborso, un invio email, una scrittura su un sistema esterno) non venga eseguita due volte per colpa di un retry.

Nessuno di questi requisiti è nuovo: sono gli stessi problemi che i sistemi distribuiti risolvono da decenni con pattern come saga, checkpointing e idempotency key. La differenza è che oggi il “servizio downstream” spesso è un LLM, e la latenza dominante non è più quella di rete, ma quella dell’attesa umana.

Durable orchestration: lo stato che sopravvive al crashIl pattern architetturale proposto è un runtime di orchestrazione durevole, che mantiene lo stato del workflow indipendentemente dal ciclo di vita del processo che lo esegue. In .NET, l’implementazione più diretta è Azure Durable Functions, che introduce tre concetti chiave:

Orchestrator function: decide “cosa succede dopo”, applica le retry policy e coordina le chiamate, ma non esegue lavoro con effetti collaterali direttamente;

Activity function: esegue il lavoro reale (chiamata al modello, query, side effect) ed è il livello dove si applica l’idempotenza;

Checkpointing automatico: dopo ogni await, il runtime salva lo stato dell’orchestrazione, così un crash del processo non fa perdere il progresso già fatto.

Un’alternativa nota, citata anche nell’articolo originale, è Temporal, che applica lo stesso principio con un modello di programmazione simile ma un runtime a sé stante, spesso preferito in contesti multi-linguaggio o Kubernetes-native.

Il pattern fan-out/fan-in per agenti multipliQuando un task richiede il contributo di più agenti specializzati (per esempio: un agente diagnostico, uno di ricerca sulla knowledge base, uno che consulta lo storico dei casi e uno che verifica le policy aziendali), il pattern corretto è il fan-out/fan-in: l’orchestratore lancia tutte le attività in parallelo e aggrega i risultati solo quando sono tutte terminate.

Ecco un esempio realistico in C# con il modello isolato di Azure Functions, ispirato agli esempi ufficiali Microsoft:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
var caseId = context.GetInput();

// Fan-out: 4 agenti specializzati lanciati in parallelo
var diagnosticTask = context.CallActivityAsync<AgentFinding>(
    "RunDiagnosticAgent", caseId);
var knowledgeTask = context.CallActivityAsync<AgentFinding>(
    "RunKnowledgeSearchAgent", caseId);
var historyTask = context.CallActivityAsync<AgentFinding>(
    "RunHistoricalCaseAgent", caseId);
var policyTask = context.CallActivityAsync<AgentFinding>(
    "RunPolicyAgent", caseId);

// Fan-in: si attende che tutti i task completino
AgentFinding[] findings = await Task.WhenAll(
    diagnosticTask, knowledgeTask, historyTask, policyTask);

// Sintesi della raccomandazione finale
var recommendation = await context.CallActivityAsync<Recommendation>(
    "SynthesizeRecommendation", findings);

return new InvestigationResult(caseId, findings, recommendation);

}Il vantaggio rispetto a un semplice Task.WhenAll in un servizio stateless è che, se il processo host crasha mentre due agenti su quattro hanno già risposto, l’orchestrazione riparte dal checkpoint e non richiama gli agenti già completati.

Human-in-the-loop senza tenere aperta la computeIl collo di bottiglia più comune non è il modello, ma l’attesa di un’approvazione umana. Un workflow che tenesse una funzione serverless “in ascolto” per ore sarebbe insostenibile in termini di costo e di timeout. Il pattern corretto è sospendere l’orchestrazione in attesa di un evento esterno:

[Function("SupportInvestigationOrchestrator")]
public static async Task<InvestigationResult> Run(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
// ... fan-out/fan-in come sopra ...

await context.CallActivityAsync("NotifyHumanReviewer", recommendation);

// Il workflow si sospende senza consumare risorse compute
// fino a quando l'evento non arriva, anche dopo diverse ore
var decision = await context.WaitForExternalEvent<HumanReviewDecision>(
    "HumanReviewCompleted");

if (decision.Approved)
{
    await context.CallActivityAsync("ApplyResolution", recommendation);
}

return new InvestigationResult(caseId, findings, recommendation, decision);

}L’evento viene “consegnato” all’orchestrazione in pausa tramite una chiamata separata (per esempio da una Function HTTP-triggered collegata a un pulsante “Approva” nella UI), e il runtime si occupa di riprendere l’esecuzione esattamente dal punto in cui era stata sospesa.

Idempotenza: il vero rischio nascostoUn runtime durevole garantisce tipicamente semantica at-least-once: dopo un crash, un’attività può essere rieseguita. Questo va benissimo per operazioni pure (una query di lettura), ma è pericoloso per operazioni con side effect (un rimborso, un invio email, una scrittura irreversibile). Il momento critico è il cosiddetto crash window: l’intervallo tra il completamento effettivo di un’azione e il salvataggio del suo checkpoint.

La soluzione è associare a ogni operazione critica una idempotency key deterministica, così che una riesecuzione accidentale venga riconosciuta e ignorata a livello applicativo:

[Function("ApplyGoodwillRefund")]
public static async Task ApplyGoodwillRefund(
[ActivityTrigger] RefundRequest request)
{
string idempotencyKey = $"{request.CaseId}:goodwill-refund";

if (await _paymentService.WasAlreadyProcessedAsync(idempotencyKey))
{
    return; // operazione già eseguita, nessun effetto collaterale duplicato
}

await _paymentService.ProcessRefundAsync(request, idempotencyKey);

}Questo pattern, ben noto a chi lavora con gateway di pagamento, va applicato sistematicamente a ogni activity che tocchi sistemi esterni non idempotenti per natura.

Successo parziale, non tutto-o-nienteSe uno dei quattro agenti fallisce (per esempio, il servizio di knowledge search va in timeout), il sistema non dovrebbe far fallire l’intera indagine. Meglio trattare i risultati come esiti strutturati, distinguendo tra “successo”, “fallito” e “degradato”, e permettere che la sintesi finale proceda comunque, segnalando esplicitamente quali fonti mancano:

public record AgentFinding(
string AgentName,
AgentStatus Status, // Success, Failed, Degraded
string? Result,
string? FailureReason);Questo approccio “graceful degradation” è preferibile a un fallimento totale che obbliga a rieseguire da capo un’indagine costosa in termini di tempo e token consumati.

Osservabilità come requisito di prodottoIn un sistema dove un’indagine può durare ore e coinvolgere quattro o più agenti, la tracciabilità non è un dettaglio tecnico: è parte dell’esperienza utente e, in molti contesti regolamentati, un requisito di audit. Vale la pena tracciare sistematicamente:

workflow instance ID, correlation ID e case ID;

lo stage corrente e la durata di ogni singolo agente;

il numero di retry e il motivo di ogni fallimento;

la latenza di revisione umana (spesso il fattore dominante);

la tracciabilità delle evidenze usate per la raccomandazione finale, per scopi di audit.

ConclusioneIl messaggio di fondo è semplice ma spesso trascurato: il workflow conta più del prompt. Un agente AI ben progettato non è quello con il prompt più raffinato, ma quello costruito su un runtime capace di sopravvivere a crash, gestire attese umane di ore senza sprecare risorse, ed evitare effetti collaterali duplicati. Per chi lavora nello stack .NET, Azure Durable Functions offre oggi gli strumenti necessari per applicare questi pattern senza dover reinventare un motore di orchestrazione da zero; per contesti poliglotta o già containerizzati, Temporal resta un’alternativa solida con la stessa filosofia.

Fonte originale: “Your AI Agent Is a Distributed System, Not a Chatbot” su DZone.

C’è una minaccia alla crittografia moderna che non richiede un computer quantistico funzionante oggi per essere reale oggi: si chiama “harvest now, decrypt later” (raccogli ora, decifra dopo). Un attaccante con risorse sufficienti — uno stato-nazione, tipicamente — può intercettare e archiviare traffico cifrato con RSA o ECC adesso, per poi decifrarlo tra qualche anno, quando computer quantistici sufficientemente potenti saranno disponibili. Per dati con un ciclo di vita lungo — segreti industriali, cartelle cliniche, comunicazioni diplomatiche, chiavi di firma di lungo periodo — la finestra di esposizione è già aperta, anche se il computer quantistico “rompi-RSA” non esiste ancora.

È in questo contesto che Microsoft ha recentemente pubblicato una guida al threat modeling applicato specificamente alla migrazione verso la crittografia post-quantistica (PQC), invitando organizzazioni e team di sviluppo a non aspettare la disponibilità degli algoritmi per cominciare a muoversi.

Perché serve il threat modeling, e non solo un elenco di algoritmiIl problema centrale che Microsoft evidenzia non è tecnico in senso stretto, è organizzativo: la maggior parte delle aziende non ha un inventario completo di dove e come viene usata la crittografia nei propri sistemi. Certificati TLS, librerie di firma incorporate in applicazioni legacy, hardware embedded con chiavi hard-coded, protocolli proprietari che usano RSA “perché si è sempre fatto così” — sono tutte dipendenze crittografiche nascoste che un aggiornamento generico non intercetta.

Il threat modeling applicato alla PQC serve esattamente a questo: mappare asset, flussi di dati, confini di fiducia (trust boundary) e controlli di sicurezza esistenti per far emergere queste dipendenze prima che diventino un problema urgente sotto pressione regolatoria o, peggio, sotto attacco. Concretamente, significa rispondere a domande come: quali sistemi cifrano dati che devono restare confidenziali per più di 5-10 anni? Quali certificati di firma del codice hanno una validità che si estende oltre il 2030? Quali protocolli interni non supportano l’agilità crittografica, cioè non permettono di sostituire un algoritmo senza riscrivere l’applicazione?

Gli algoritmi: da NIST a nomi che iniziano a essere familiariDopo anni di standardizzazione, il NIST ha pubblicato tre standard che è ormai il momento di conoscere, perché stanno entrando nei prodotti che usiamo quotidianamente:

ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203) — sostituisce lo scambio di chiavi basato su RSA o curve ellittiche (ECDH). È l’algoritmo che entra in gioco nell’handshake TLS per stabilire un segreto condiviso.

ML-DSA (Module-Lattice Digital Signature Algorithm, FIPS 204) — l’algoritmo di firma digitale post-quantistico, pensato come sostituto di RSA e ECDSA per firmare certificati, codice e messaggi.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) — un algoritmo di firma alternativo, basato su funzioni hash anziché su reticoli, pensato come backup conservativo nel caso in cui in futuro emergano debolezze crittanalitiche nei problemi su reticolo.

Sul fronte delle raccomandazioni pratiche, Microsoft insiste su un punto spesso sottovalutato: la migrazione a TLS 1.3 è il prerequisito, non un dettaglio. TLS 1.2 non supporta i meccanismi ibridi necessari per introdurre ML-KEM accanto agli algoritmi classici, e restare su TLS 1.2 significa restare bloccati fuori dalla transizione PQC anche quando gli algoritmi saranno pronti. In parallelo, si consiglia di alzare l’asticella anche sulla crittografia simmetrica e sulle funzioni hash, adottando AES-256 e SHA-384 come standard, per mantenere margini di sicurezza adeguati anche in scenari quantistici (dove alcuni attacchi, come Grover, dimezzano di fatto la sicurezza effettiva degli algoritmi simmetrici).

La timeline che Microsoft si è data per la transizione dei propri prodotti e servizi critici è il 2029 — una data che vale la pena tenere a mente come riferimento di settore, anche per pianificare le proprie migrazioni interne con lo stesso ordine di grandezza.

Cosa c’è già oggi: le API disponibiliLa parte più interessante per chi scrive codice è che la PQC non è più solo teoria da paper accademico: le API sono già disponibili e generalmente disponibili (GA) sulle piattaforme Microsoft.

Windows: CNGSu Windows, il supporto arriva a livello di CNG (Cryptography API: Next Generation), con identificatori di algoritmo dedicati per ML-KEM e ML-DSA utilizzabili tramite le funzioni BCryptGenerateKeyPair e le relative API di key exchange e firma. Il supporto nativo è arrivato a partire da Windows 11 con gli aggiornamenti di novembre 2025: chi gestisce flotte Windows dovrebbe verificare di essere allineato con le patch più recenti prima di pianificare qualunque test.

.NET 10: MLKem e MLDsa in System.Security.CryptographyPer chi sviluppa in C#, la notizia più concreta è l’arrivo delle classi MLKem e MLDsa direttamente in System.Security.Cryptography con .NET 10. Ecco un esempio minimo di key encapsulation:

using System.Security.Cryptography;

if (!MLKem.IsSupported)
{
Console.WriteLine("ML-KEM non è supportato su questa piattaforma");
return;
}

MLKemAlgorithm alg = MLKemAlgorithm.MLKem768;

using (MLKem privateKey = MLKem.GenerateKey(alg))
using (MLKem publicKey = MLKem.ImportEncapsulationKey(
alg, privateKey.ExportEncapsulationKey()))
{
publicKey.Encapsulate(out byte[] ciphertext, out byte[] sharedSecret1);
byte[] sharedSecret2 = privateKey.Decapsulate(ciphertext);

bool match = sharedSecret1.AsSpan().SequenceEqual(sharedSecret2);
Console.WriteLine($"I segreti condivisi coincidono: {match}");

}E un esempio di firma con ML-DSA:

MLDsaAlgorithm alg = MLDsaAlgorithm.MLDsa65;

using (MLDsa key = MLDsa.GenerateKey(alg))
{
byte[] data = "Messaggio da firmare"u8.ToArray();
byte[] signature = new byte[alg.SignatureSizeInBytes];

key.SignData(data, signature);
bool verified = key.VerifyData(data, signature);

Console.WriteLine($"Firma verificata: {verified}");

}Entrambe le famiglie di algoritmi sono disponibili in più varianti — MLKem512, MLKem768, MLKem1024 per il key encapsulation, e MLDsa44, MLDsa65, MLDsa87 per la firma — con un compromesso crescente tra sicurezza e dimensione delle chiavi. Ad esempio, per MLDsa65 la chiave pubblica occupa 1952 byte, quella privata 4032 byte e la firma 3309 byte: numeri sensibilmente più grandi rispetto a ECDSA, un dettaglio da tenere presente quando si progettano protocolli o formati di messaggio con vincoli di banda o storage.

Un paio di note pratiche per chi vuole sperimentare da subito: su Linux serve OpenSSL 3.5 o superiore, mentre chi è ancora su .NET Standard 2.0 può accedere alle stesse API tramite il pacchetto NuGet Microsoft.Bcl.Cryptography. Per il supporto lato TLS 1.3, certificati basati su ML-DSA e SLH-DSA funzionano già in scenari di autenticazione quando sia il sistema operativo sia la controparte della connessione supportano i nuovi algoritmi — un altro motivo per cui la coordinazione tra client e server nella transizione non è opzionale.

Da dove cominciare, in praticaPer un team che affronta questo tema per la prima volta, un percorso ragionevole è: primo, effettuare un inventario reale di certificati, librerie crittografiche e protocolli in uso, distinguendo per criticità e durata di vita dei dati protetti; secondo, verificare che l’infrastruttura TLS sia già su 1.3 ovunque possibile, perché è il prerequisito tecnico per tutto il resto; terzo, iniziare a sperimentare le nuove API — su .NET 10 il costo di ingresso è basso, si tratta di poche righe di codice — in ambienti non di produzione, per capire l’impatto su dimensioni di chiavi, firme e tempi di calcolo prima che diventi un requisito con scadenza stretta.

La crittografia post-quantistica non è ancora un’emergenza operativa per la maggior parte delle organizzazioni, ma il messaggio di Microsoft è chiaro: il momento di mappare le proprie dipendenze crittografiche e cominciare a testare gli algoritmi è adesso, non quando arriverà l’obbligo normativo o il primo incidente.

Fonte originale: Microsoft Urges Threat Modeling to Prepare for Post-Quantum Cryptography Migration, Petri IT Knowledgebase

Quando una vulnerabilità critica in un prodotto enterprise passa dalla ricerca accademica allo sfruttamento attivo nel giro di poche settimane, il tempo a disposizione dei team IT per applicare la patch si riduce drasticamente. È esattamente quello che sta succedendo con CVE-2026-55040, un bypass di autenticazione in Microsoft SharePoint Server che, dopo la pubblicazione di un proof-of-concept dettagliato, è ora oggetto di tentativi di exploitation attiva da IP distribuiti in più paesi. Per chi gestisce ambienti SharePoint on-premises, capire il meccanismo dell’attacco è il primo passo per dare priorità corretta alla remediation.

Cos’è CVE-2026-55040La vulnerabilità, con punteggio CVSS 3.1 pari a 9.1 (critico) e classificata come CWE-1390 (Weak Authentication), risiede nella pipeline di validazione dei token JWT usata da SharePoint per l’autenticazione server-to-server (S2S). Il risultato pratico è che un attaccante non autenticato, conoscendo l’identificativo di un utente (il SID di Active Directory o lo UPN), può forgiare un token che SharePoint accetta come legittimo — arrivando fino all’impersonificazione di un account amministrativo.

Sono colpite tre versioni principali del prodotto:

SharePoint Server Subscription Edition (build 16.0.19725.20434 e precedenti)

SharePoint Server 2019 (build 16.0.10417.20175 e precedenti)

SharePoint Enterprise Server 2016 (build 16.0.5561.1001 e precedenti)

Come funziona il bypassL’analisi tecnica pubblicata da Rapid7 Labs descrive una catena di quattro debolezze concatenate nel processo di verifica dei token Bearer S2S, che nel loro insieme permettono di costruire un token accettato senza una firma crittografica valida: un header che dichiara un algoritmo di firma “none”, l’uso del certificato STS di SharePoint stesso come chiave di firma anziché come verificatore, un certificato non correttamente validato contro TrustedSecurityTokenServices, e — punto più critico — la firma del token che di fatto non viene mai verificata end-to-end.

In pratica, un attaccante che conosce (o enumera) l’identificativo di un utente può costruire un token che SharePoint tratta come proveniente da un servizio fidato, ottenendo l’accesso alle API e alle risorse del sito con i privilegi di quell’utente — amministratore incluso, se il SID target è quello giusto.

Perché è particolarmente pericolosaTre fattori la rendono un rischio prioritario rispetto alla media delle CVE mensili:

Nessuna autenticazione richiesta: l’attaccante non ha bisogno di credenziali valide, solo della conoscenza (o della capacità di enumerare) l’identificativo dell’utente target.

PoC pubblico e riproducibile: la disponibilità di un exploit funzionante abbassa drasticamente la barriera tecnica per chi vuole sfruttarla, come dimostra l’aumento dei tentativi osservati nei giorni successivi alla pubblicazione.

Superficie di attacco diretta: qualsiasi istanza SharePoint on-premises esposta a Internet, anche solo per l’accesso remoto di dipendenti o partner, è un bersaglio potenziale.

Cosa mostra la telemetria degli attacchiSecondo i dati di tracking condivisi dalla community di threat intelligence (KEVIntel), i primi tentativi di sfruttamento risalgono al 19 luglio 2026, con una intensificazione marcata nei giorni successivi alla pubblicazione del PoC — otto tentativi registrati solo tra il 12 e il 13 agosto, provenienti da otto indirizzi IP distinti localizzati tra Hong Kong, Giappone, Paesi Bassi, Taiwan e Stati Uniti. Un pattern tipico delle campagne opportunistiche che seguono la pubblicazione di un exploit pubblico: scansioni automatizzate su larga scala alla ricerca di istanze non ancora aggiornate.

Patch e mitigazioniMicrosoft ha già rilasciato gli aggiornamenti correttivi; il primo passo per qualsiasi team che gestisce SharePoint on-premises è verificare di aver applicato i seguenti KB in base alla versione in uso:

SharePoint Server Subscription Edition → KB5002882
SharePoint Server 2019 → KB5002883
SharePoint Enterprise Server 2016 → KB5002891Oltre all’applicazione della patch, che resta la mitigazione principale, vale la pena eseguire una checklist di hardening più ampia:

Verificare la build corrente tramite l’interfaccia di amministrazione centrale o PowerShell (Get-SPFarm | Select BuildVersion), confrontandola con le versioni corrette rilasciate da Microsoft.

Analizzare i log IIS e ULS alla ricerca di pattern di richieste anomale verso gli endpoint di autenticazione S2S, in particolare token Bearer con struttura o claim inusuali.

Ridurre l’esposizione diretta a Internet dei server SharePoint on-premises dove non strettamente necessario, preferendo l’accesso tramite VPN o reverse proxy con autenticazione aggiuntiva.

Segmentare la rete in modo che un’eventuale compromissione del front-end SharePoint non dia accesso diretto ad altri sistemi interni.

Rivedere gli account con privilegi elevati su SharePoint, applicando il principio del privilegio minimo e monitorando le attività degli account amministrativi per individuare comportamenti anomali successivi alla finestra di esposizione.

ConclusioneCVE-2026-55040 è un promemoria diretto di quanto velocemente un bypass di autenticazione ben documentato possa trasformarsi in sfruttamento attivo su scala. Per chi amministra ambienti SharePoint on-premises, la priorità immediata è verificare lo stato delle patch KB5002882/KB5002883/KB5002891 e, in assenza di conferma dell’aggiornamento, trattare l’istanza come potenzialmente compromessa fino a prova contraria — controllando log di autenticazione e attività degli account amministrativi nella finestra temporale in cui la vulnerabilità è rimasta senza patch.

Fonti: Petri IT Knowledgebase, Rapid7 Labs, The Hacker News

Il SOC incontra il GitOpsCon l’aggiornamento di luglio 2026, Microsoft Sentinel porta la logica DevOps fin dentro il cuore del rilevamento delle minacce: le regole di detection personalizzate entrano ufficialmente tra i contenuti gestibili come Detections-as-Code (DaC) tramite le Sentinel Repositories, mentre un nuovo pannello Table Insights rende finalmente leggibile a colpo d’occhio lo stato di salute dell’ingestion. Sono due funzionalità distinte ma complementari, ed entrambe parlano direttamente a chi in azienda gestisce SIEM e pipeline CI/CD con lo stesso approccio.

Detections-as-Code: le regole di rilevamento come contenuto versionatoMicrosoft Sentinel Repositories esisteva già per contenuti come analytics rules, automation rules, hunting queries, parser, playbook e workbook: la novità è che ora anche le regole di detection personalizzate (custom detection rules) rientrano in questo flusso, gestibili tramite la Microsoft Security Bicep extension. Il repository esterno — GitHub o Azure DevOps — diventa la single source of truth: qualunque modifica fatta manualmente dal portale di Sentinel viene sovrascritta alla successiva sincronizzazione dal repository.

Per collegare un repository servono permessi precisi, spesso motivo di attrito nei team più strutturati:

ruolo Owner sul resource group che contiene il workspace Sentinel, per creare la connessione;

accesso Collaborator sul repository GitHub, oppure Project Administrator su Azure DevOps;

GitHub Actions abilitate (o Pipelines per Azure DevOps);

per Azure DevOps, la connessione deve risiedere nello stesso tenant del workspace Sentinel.

Ogni workspace Sentinel è limitato a cinque connessioni repository, e ogni resource group a 800 deployment nella sua history — un limite da tenere presente se si pianifica una struttura multi-repo per team o ambienti diversi.

Bicep, non ARM JSON: la scelta consigliataMicrosoft consiglia esplicitamente Bicep rispetto ai template ARM JSON grezzi per descrivere le regole. Un paio di dettagli tecnici da non sottovalutare in fase di migrazione:

i file Bicep non supportano la proprietà id: le regole esportate da Sentinel la includono, e va rimossa manualmente prima della decompilazione;

per una decompilazione pulita da ARM JSON a Bicep conviene forzare lo schema alla versione 2019-04-01;

le connessioni create prima del 1° novembre 2024 non supportano Bicep e vanno rimosse e ricreate per abilitarlo.

Per chi parte da zero, il repository ufficiale SentinelCICD/RepositoriesSampleContent fornisce template di esempio per ogni tipo di contenuto, comprese le funzionalità avanzate delle connessioni repository.

Smart deployments: non ridistribuire ciò che non è cambiatoUna delle frizioni tipiche del content-as-code applicato a un SIEM è il rischio di ridistribuire regole invariate a ogni deploy, resettando ad esempio schedule dinamici delle analytics rule. Sentinel risolve il problema con gli smart deployments: un file CSV nella cartella .sentinel del repository tiene traccia dei commit e il workflow evita di ridistribuire contenuti non modificati dall’ultimo deploy. È abilitato di default sulle nuove connessioni; per disattivarlo (e forzare sempre il deploy completo) si interviene sul file YAML del workflow o della pipeline.

Il flusso operativo tipico diventa quindi: un analista propone una nuova regola di detection in una pull request, il team la revisiona come farebbe con codice applicativo, al merge la pipeline CI/CD (GitHub Actions o Azure Pipelines) distribuisce automaticamente solo le modifiche nel workspace Sentinel collegato — con audit trail completo su chi ha cambiato cosa e quando, cosa che il portale da solo non garantisce con la stessa granularità.

Table Insights: capire l’ingestion senza scrivere KQLLa seconda novità rilevante del mese è Table Insights, un nuovo pannello nella pagina Tables della configurazione di Sentinel (Defender portal → Microsoft Sentinel → Configuration → Tables). Mostra, senza bisogno di query KQL manuali:

il volume di ingestion degli ultimi 30 giorni, suddiviso per tier (Analytics vs Auxiliary/Data Lake);

le variazioni giorno su giorno e settimana su settimana, utili per individuare picchi o cali anomali;

le tabelle che consumano più ingestion, per stimare rapidamente i costi;

i connettori che hanno smesso di inviare dati — spesso il primo sintomo di un problema di raccolta che altrimenti si scopre solo durante un’investigazione, quando è troppo tardi.

Chi preferisce restare in KQL può ottenere una vista equivalente sfruttando il campo Plan della tabella Usage, che permette di scomporre l’ingestion per Analytics, Basic e Auxiliary direttamente in query native — utile per costruire dashboard personalizzate o alert di costo oltre al pannello grafico.

Nuovi connettori datiL’aggiornamento di luglio amplia anche la copertura dei data connector con il supporto nativo per GitHub Enterprise, Agari, Airlock Digital e Gigamon — un’estensione che si allinea bene proprio con l’adozione di Detections-as-Code, dato che GitHub Enterprise diventa ora sia sorgente di log di audit sia repository di regole.

Perché conviene iniziare oraPer un SOC maturo, la combinazione di queste due funzionalità è più significativa della somma delle parti: Detections-as-Code porta revisione tra pari, versionamento e rollback affidabile sulle regole di rilevamento, mentre Table Insights riduce il tempo necessario per accorgersi che una sorgente di log si è interrotta silenziosamente — un problema che, senza query dedicate, spesso passa inosservato per settimane. Chi gestisce già Infrastructure-as-Code su Azure con Bicep o Terraform troverà il modello concettuale familiare; la parte più delicata resta la migrazione delle regole esistenti dal portale al repository, che conviene pianificare per gruppi di severità o per data source, non tutta insieme.

Fonte: Petri IT Knowledgebase – Microsoft Sentinel Adds Detections-As-Code, Table Insights, and New Data Connectors, con approfondimenti dalla documentazione ufficiale Microsoft Learn su Sentinel Repositories.

Chi amministra Microsoft #Entra ID conosce bene il problema dei “gruppi nidificati”: per anni non è stato possibile costruire un gruppo dinamico che includesse automaticamente i membri di un altro gruppo. La regola preview memberOf, introdotta proprio per colmare questa lacuna, sta però per essere ritirata. Dal 3 novembre 2026 tutte le configurazioni che la usano smetteranno di aggiornarsi, restando congelate all’ultimo stato elaborato correttamente. Se gestite gruppi dinamici, unità amministrative dinamiche o policy di entitlement management basate su memberOf, è il momento di pianificare la migrazione.

Cos’è (stato) l’operatore memberOfIn anteprima pubblica, memberOf ha permesso di creare gruppi a membership dinamica popolati a partire dall’appartenenza ad altri gruppi, di sicurezza, Microsoft 365 o sincronizzati da Active Directory on-premises. La regola si scriveva nella sintassi avanzata del rule editor, non essendo mai stata supportata dal rule builder grafico:

// Regola per un gruppo dinamico di utenti
user.memberof -any (group.objectId -in ['<groupObjectId>'])

// Regola per un gruppo dinamico di device
device.memberof -any (group.objectId -in ['<groupObjectId>'])

// Più gruppi sorgente contemporaneamente
user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])Era possibile usarla per gruppi dinamici veri e propri, per unità amministrative dinamiche e per policy di auto-assignment in Entra ID Governance, con limiti già stringenti in preview: 500 gruppi memberOf per tenant, massimo 50 gruppi sorgente per regola, nessuna combinazione con altri operatori o con altre regole memberOf annidate.

Perché Microsoft la ritiraDurante la preview, Microsoft ha osservato che l’uso di memberOf può rallentare l’elaborazione della membership dinamica per tutti i gruppi del tenant, non solo per quelli che la utilizzano: un singolo gruppo configurato con questo operatore può introdurre ritardi di elaborazione a livello di tenant. Per questo motivo Microsoft ha deciso di ritirare l’operatore dalla preview, pur riconoscendo la validità dello scenario d’uso, e sta sviluppando una soluzione alternativa più scalabile, senza però fornire ancora una data di disponibilità.

Cosa succede dopo il 3 novembre 2026Le configurazioni che usano ancora memberOf non genereranno errori visibili: semplicemente smetteranno di aggiungere o rimuovere membri quando cambia l’appartenenza ai gruppi sorgente, restando congelate all’ultimo stato noto. È un comportamento subdolo perché non c’è un evento di rottura evidente, solo un progressivo disallineamento tra la realtà organizzativa e ciò che Entra ID applica. Gli effetti possono includere:

Accessi Teams e SharePoint non più aggiornati per utenti entrati o usciti da un gruppo sorgente

Targeting delle policy di Conditional Access basato su appartenenze obsolete

Licenze assegnate tramite group-based licensing non più coerenti con l’organico reale

Ambiti amministrativi (administrative unit) che non riflettono più la struttura corrente

Assegnazioni di access package in Entra ID Governance bloccate sullo stato congelato

Come prepararsi: audit prima della deadlineIl primo passo è mappare ogni configurazione che dipende da memberOf. Per i gruppi dinamici, si può esportare l’elenco dall’Entra admin center oppure interrogare Microsoft Graph #PowerShell cercando la stringa nella proprietà MembershipRule:

Connect-MgGraph -Scopes "Group.Read.All"

Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
-Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' } |
Select-Object Id, DisplayName, MembershipRulePer le unità amministrative dinamiche e le policy di auto-assignment dell’entitlement management non esiste (ancora) un filtro diretto lato server sulla regola: occorre enumerare gli oggetti e verificare la proprietà della regola dinamica, ad esempio:

Unità amministrative dinamiche

Get-MgDirectoryAdministrativeUnit -All -Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' }

Policy di auto-assignment (Entitlement Management)

Get-MgEntitlementManagementAccessPackageAssignmentPolicy -All |
Where-Object { $_.AutomaticRequestSettings.RequestAccessForAllowedTargets -ne $null }Per le policy di entitlement management è comunque consigliabile incrociare l’output con la revisione manuale in Entra ID Governance, dato che la struttura della regola può variare a seconda di come è stata configurata.

Strategie di migrazioneUna volta identificate le configurazioni a rischio, Microsoft indica due strade principali:

Sostituire la regola con operatori dinamici supportati (ad esempio basati su attributi utente o dispositivo), quando esiste un equivalente funzionale

Convertire a membership assegnata quando non è possibile replicare la logica di nesting con le regole standard, accettando la gestione manuale o tramite automazione esterna (es. script PowerShell schedulati o Logic App)

In entrambi i casi, prima di considerare chiusa la migrazione bisogna validare concretamente: verificare che la membership finale del gruppo coincida con quella attesa, controllare che le assegnazioni di licenza, gli scope di Conditional Access e i pacchetti di accesso continuino a comportarsi correttamente, ed eliminare le configurazioni ormai inutilizzate invece di lasciarle come debito tecnico silente.

ConclusioneIl ritiro di memberOf è un promemoria di un principio più generale nel #cloud amministrato: le funzionalità in preview non vanno mai considerate stabili in produzione, per quanto risolvano un problema reale. Con circa tre mesi di margine dalla data di scrittura di questo articolo al 3 novembre 2026, il momento giusto per l’audit è ora, prima che il “congelamento” silenzioso della membership diventi un problema di accesso scoperto in produzione da un utente che segnala di aver perso l’accesso a un canale Teams.

Fonte: Microsoft Learn – Configure dynamic membership groups with the memberOf operator, con approfondimenti da 4sysops e Petri IT Knowledgebase.

Un malware che usa il calendario di Outlook come dead-dropA metà luglio 2026 il team di Threat Intelligence di Group-IB ha pubblicato un’analisi tecnica su HOLLOWGRAPH, un impianto malevolo che ribalta un’assunzione su cui molte architetture di sicurezza si basano ancora: se il traffico esce verso graph.microsoft.com con un token valido, allora è “legittimo”. HOLLOWGRAPH dimostra che non è più così, e lo fa in un modo che vale la pena capire in dettaglio anche per chi non si occupa di threat intelligence, perché le tecniche di evasione che usa (abuso di API cloud fidate, DNS tunneling, cifratura ibrida) sono ormai pattern ricorrenti e replicabili.

Il malware è attribuito con alta confidenza al framework di backdoor modulare Cavern, già collegato ad attività di cyberspionaggio riconducibili all’area di influenza iraniana (con sovrapposizioni tecniche, seppur a bassa confidenza, con il gruppo Lyceum). La campagna osservata ha colpito in modo mirato organizzazioni israeliane: 12 sistemi compromessi identificati, di cui solo 3 attivamente in comunicazione con l’attaccante al momento dell’analisi — un profilo operativo selettivo, non opportunistico.

Il calendario come canale C2 bidirezionaleL’idea centrale di HOLLOWGRAPH è semplice da spiegare e proprio per questo efficace: invece di contattare un server C2 sotto il controllo dell’attaccante, il malware autentica una mailbox Microsoft 365 compromessa tramite Microsoft Graph API e usa il calendario di quella mailbox come dead-drop bidirezionale.

Il malware supporta solo due comandi:

get — cerca eventi del calendario con oggetto Event ID: <taskID>, programmati per il 13 maggio 2050 (una data lontana nel futuro, scelta per non comparire mai nella vista “prossimi eventi” del proprietario della mailbox), scarica gli allegati e li decifra con la chiave privata RSA incorporata nel binario.

send — cifra i dati da esfiltrare, crea un nuovo evento con la stessa data fittizia, carica i dati come allegati File{n}.txt e rinomina l’oggetto dell’evento con un tag riconoscibile dall’operatore (schema Boss{..}ID{..}).

Le chiamate Graph coinvolte sono quelle che qualunque applicazione legittima con permessi calendario userebbe normalmente:

GET /users/{mailbox}/calendarView
?startDateTime=2050-05-13T22:00:00
&endDateTime=2050-05-13T23:00:00
&$filter=contains(subject,'Event ID: ')

POST /users/{mailbox}/calendar/events
POST /users/{mailbox}/events/{event-id}/attachments
PATCH /users/{mailbox}/events/{event-id}Non c’è nulla in queste richieste che le distingua sintatticamente da un utente che crea un invito a una riunione. È questo il punto: il traffico malevolo non anomalizza il protocollo, sfrutta la fiducia implicita che i controlli di rete perimetrali attribuiscono al dominio graph.microsoft.com.

Cifratura ibrida e rinnovo credenziali via DNS tunnelingOgni payload scambiato tramite il calendario è protetto con uno schema ibrido RSA-OAEP + AES-256-GCM, con due coppie di chiavi RSA distinte per le due direzioni (tasking in ingresso ed esfiltrazione in uscita), così che comandi e dati rubati restino crittograficamente indipendenti l’uno dall’altro anche in caso di compromissione parziale.

Il secondo canale, separato, serve a rinnovare le credenziali Microsoft Entra ID (tenant ID, client ID, client secret, indirizzo della mailbox) necessarie per autenticarsi a Graph. Qui HOLLOWGRAPH usa DNS tunneling su record AAAA verso un dominio controllato dall’attaccante (cloudlanecdn[.]com):

LENGTH query: {random}.{taskID}.{fieldIndex}.p.cloudlanecdn.com
DATA query: {random}.{taskID}.{fieldIndex}.{offset}.q.cloudlanecdn.comOgni risposta IPv6 restituita (16 byte) trasporta 14 byte di payload utile; il client ricompone i frammenti, li decodifica come UTF-8 e aggiorna un file di configurazione locale (logAzure.txt) mascherato da comune file di log. L’uso di IPv6/AAAA anziché dei più monitorati record TXT o A è una scelta non casuale: molte pipeline di DNS analytics sono ancora tarate prevalentemente su IPv4.

Perché elude i controlli tradizionaliTre fattori rendono HOLLOWGRAPH difficile da individuare con gli strumenti perimetrali classici:

Il traffico C2 viaggia interamente su infrastruttura Microsoft fidata (Graph API), quindi non compare in nessuna blocklist di reputazione IP o dominio.

Non c’è mai una connessione diretta a un server dell’attaccante per il tasking o l’esfiltrazione: solo il canale di rinnovo credenziali tocca un dominio esterno, e lo fa via DNS, spesso meno ispezionato del traffico HTTPS.

Gli eventi di calendario datati 2050 sono progettati per restare invisibili all’utente reale della mailbox, che normalmente non scorre trent’anni avanti nel proprio calendario.

Cosa può fare concretamente un team di sicurezzaLe raccomandazioni di Group-IB si traducono in azioni piuttosto precise per chi gestisce ambienti Microsoft 365 / Entra ID:

Caccia agli indicatori noti. Bloccare o mettere in allerta su richieste verso cloudlanecdn[.]com e cercare sugli endpoint il file logAzure.txt.

Monitoraggio Graph API e audit di calendario. Con Microsoft Sentinel o Defender Advanced Hunting è possibile costruire una query che cerchi eventi di calendario creati da un’applicazione (non da un utente interattivo) con oggetto sospetto o data anomala:

CloudAppEvents
| where Application == "Microsoft Exchange Online"
| where ActionType in ("New item created.", "New-CalendarItem")
| extend AppId = tostring(RawEventData.ClientAppId)
| where isnotempty(AppId)
| extend Subject = tostring(RawEventData.ItemSubject)
| where Subject matches regex @"Event ID: |Boss{.}ID{.}"
| project Timestamp, AccountDisplayName, AppId, Subject, RawEventDataRilevamento di DNS tunneling. Una query di partenza per individuare volumi anomali di query AAAA verso lo stesso dominio, con sottodomini ad alta entropia:

DnsEvents
| where QueryType == "AAAA"
| extend RootDomain = strcat(split(Name, ".")[-2], ".", split(Name, ".")[-1])
| summarize QueryCount = count(), DistinctSubdomains = dcount(Name) by Computer, RootDomain
| where QueryCount > 200 and DistinctSubdomains > 100
| order by QueryCount descIrrigidire l’identità cloud. Applicare Conditional Access con restrizioni sulle app registrate che usano client-credentials flow, generare alert sulla creazione di nuovi client secret e ruotare periodicamente le credenziali applicative — HOLLOWGRAPH dipende interamente da un set di credenziali Entra ID statiche incorporate nel binario: se quelle credenziali vengono revocate o ruotate, il canale Graph smette di funzionare finché l’attaccante non le rinnova via DNS tunneling, un’operazione che a sua volta genera telemetria rilevabile.

ConclusioneHOLLOWGRAPH non introduce tecniche crittografiche nuove né exploit in Microsoft Graph: il suo valore per l’attaccante sta tutto nel mimetismo. Per i team che gestiscono tenant Microsoft 365, il takeaway pratico non è “bloccare Graph API” — impossibile in qualunque organizzazione moderna — ma spostare parte della detection dal perimetro di rete alla telemetria applicativa: audit log di Exchange Online, anomalie nei permessi delle app registrate, e DNS analytics capace di guardare oltre i soliti record A/TXT. È un promemoria che vale la pena avere in mente ogni volta che si progetta un controllo di sicurezza basato solo sulla reputazione del dominio di destinazione.

Fonte: Group-IB Threat Intelligence, “HOLLOWGRAPH: Turning Microsoft 365 Calendars into Covert Command-and-Control Channels” e Petri IT Knowledgebase.

Se la vostra organizzazione ha già spostato la maggior parte dei carichi rivolti agli utenti su Microsoft 365, Intune e Microsoft Entra ID, è lecito chiedersi perché esista ancora un Domain Controller che gira in produzione. La risposta più comune è “così abbiamo sempre fatto”, ed è esattamente la definizione di debito tecnico: un’infrastruttura che continua a costare in manutenzione, superficie di attacco e complessità operativa senza generare più un valore proporzionato. L’identità ibrida, con Entra Connect che sincronizza un Active Directory locale verso il cloud, è diventata per molte aziende proprio questo tipo di debito.

Non si tratta di demonizzare l’ibrido: per organizzazioni con applicazioni legacy pesantemente dipendenti da NTLM, LDAP o Kerberos, mantenere un ponte con l’on-premise è spesso l’unica scelta razionale. Il punto è che la decisione va presa consapevolmente, dopo un inventario reale delle dipendenze, e non per inerzia.

Perché il cloud-only conviene, quando è applicabilePer un’organizzazione che gira già prevalentemente su Entra ID, Microsoft 365 e client Windows moderni, il modello cloud-only centralizza la gestione IT e accelera l’accesso a nuove funzionalità di sicurezza che spesso arrivano prima, o esclusivamente, sui tenant che non dipendono più da sincronizzazione ibrida. I vantaggi concreti che spingono in questa direzione sono quattro:

Riduzione del carico operativo: patching, alta disponibilità e scalabilità dei Domain Controller passano al provider cloud.

Postura di sicurezza migliore: funzionalità come Conditional Access granulare, Identity Protection e governance degli accessi privilegiati sono nativamente più semplici da applicare senza il vincolo di compatibilità con AD locale.

Costi più prevedibili: si eliminano hardware ridondante, licenze Windows Server per i DC e il tempo ingegneristico dedicato a mantenerli in salute.

Velocità di adozione: nuove capacità (passkey, agenti AI con identità propria, automazioni Conditional Access) arrivano più rapidamente su tenant che non devono conciliarsi con un’infrastruttura ibrida.

L’errore più comune: migrare l’infrastruttura prima di validare le dipendenzeIl fallimento tipico di un progetto cloud-only non è tecnico, è di sequenza: i team iniziano a spegnere server e migrare workload prima di aver mappato davvero cosa dipende ancora da Active Directory. Un approccio più solido segue queste fasi.

1. Mappare i carichi di lavoro che bloccano il cloud-onlyPartite da un audit completo di infrastruttura, applicazioni, dati e dipendenze. Non fermatevi alla lista delle VM: cercate esplicitamente le dipendenze che raramente compaiono nei piani di migrazione di alto livello, perché sono quelle che tengono in vita Entra Connect molto più a lungo del necessario:

Applicazioni che richiedono ancora query LDAP dirette

Service account legacy non documentati

Applicazioni con autenticazione NTLM hard-coded

Impostazioni di Group Policy che nessuno ha mai rivisto

Servizi certificati (ADCS) che presuppongono un Domain Controller sempre raggiungibile

2. Definire l’architettura cloud che volete davvero gestireStabilite obiettivi chiari su performance, disponibilità, sicurezza e compliance prima di scegliere gli strumenti. Decidete se una strategia single-cloud o multi-cloud è coerente con la vostra tolleranza al rischio e con le competenze del team, non solo con il marketing del vendor.

3. Modernizzare l’identità prima di spegnere Active DirectoryQui sta il cuore del progetto. Rivedere la strategia IAM significa garantire autenticazione robusta, accesso a privilegio minimo e protezione dell’identità sfruttando gli strumenti nativi di Entra ID per unificare la gestione utenti su tutti i servizi, invece di replicare in cloud le stesse logiche pensate per un dominio locale.

4. Ridisegnare la connettività attorno all’accesso cloud, non al data centerMolte architetture di rete sono ancora progettate assumendo che il traffico debba passare da un data center centrale. Un modello cloud-only ribalta la logica: la connettività va progettata per l’accesso diretto ai servizi cloud, sfruttando le backbone dei provider e i servizi di sicurezza integrati, sia per utenti in ufficio sia da remoto.

5. Trattare le applicazioni legacy come il vero collo di bottigliaFile share, servizi di stampa, applicazioni gestionali interne e integrazioni con piattaforme di terze parti datate sono i blocchi reali dei progetti cloud-only, molto più della migrazione di VM o storage. Un’applicazione finance che si aspetta autenticazione Windows integrata, un sistema di magazzino che dipende da query LDAP o una file share con permessi ereditati da anni possono rallentare il progetto più di qualunque altro fattore. Per ciascuna, valutate lift-and-shift, refactoring o riscrittura in base a complessità e valore strategico.

6. Ricostruire la governance per un modello operativo cloud-firstAggiornate le policy per riflettere una postura cloud-first, automatizzate il reporting di compliance e sfruttate strumenti di sicurezza nativi cloud per cifratura, rilevamento minacce e incident response, invece di adattare policy pensate per l’on-premise.

7. Preparare il team IT al cambio operativoInvestite nella formazione sulle competenze cloud-specifiche, comunicate i cambiamenti con chiarezza e create canali di supporto e feedback per intercettare problemi prima che diventino bloccanti.

Cosa si rompe per primo in una migrazione cloud-onlyAnche con una pianificazione accurata, alcuni punti critici emergono quasi sempre:

Dipendenze nascoste da Active Directory: connessioni LDAP hard-coded, service account non gestiti, applicazioni dipendenti da NTLM o flussi di autenticazione mai documentati. Vanno inventariati prima di ritirare i Domain Controller o disattivare la sincronizzazione.

Blocchi operativi da Conditional Access e MFA: l’enforcement di Conditional Access e multi-factor authentication migliora la sicurezza, ma una sequenza sbagliata può bloccare fuori gli amministratori o interrompere l’accesso a servizi critici. Testate sempre account di emergenza, opzioni di rollback e flussi di accesso privilegiato prima di un enforcement ampio.

Resistenza culturale: il cambiamento comporta rischio percepito; serve chiarezza sui benefici e sui nuovi ruoli per ridurre lo scetticismo dei team.

Interruzioni di servizio: pianificate la migrazione a fasi, con pilot e backup, per minimizzare l’impatto sul business.

Il test pratico per capire quanto siete lontani dal cloud-onlySe la vostra organizzazione ha già adottato Microsoft 365, Intune ed Entra ID per la maggior parte dei carichi rivolti agli utenti, l’identità ibrida va trattata come debito tecnico, a meno che non abbiate una ragione precisa e documentata per mantenerla. Prima di pianificare una migrazione cloud-only, identificate ogni dipendenza residua da Active Directory: se la maggior parte supporta già l’autenticazione moderna, probabilmente siete più vicini al cloud-only di quanto pensiate.

Per i sistemisti che gestiscono ambienti Microsoft, il consiglio pratico è iniziare da un inventario mirato: interrogate Entra Connect per capire quali oggetti sincronizzati sono ancora effettivamente in uso, verificate quali applicazioni autenticano ancora tramite Kerberos/NTLM controllando i log di sicurezza dei Domain Controller, e mappate le Group Policy applicate per capire quali impostazioni di sicurezza andranno ricreate tramite Intune prima di spegnere l’ultimo controller di dominio.

ConclusioneLa migrazione a cloud-only non è un progetto infrastrutturale, è un progetto di identità. Le organizzazioni che falliscono di solito partono dal lato sbagliato del problema, migrando VM e storage prima di aver capito cosa dipende ancora da un dominio Active Directory che nessuno ha mai documentato del tutto. Chi parte invece dall’inventario delle dipendenze di identità, tratta l’ibrido come uno stato temporaneo e non come un’architettura permanente, arriva a un ambiente più semplice da gestire, più sicuro per costruzione e meno costoso da mantenere nel tempo.

Fonte: Why Hybrid Identity Becomes Technical Debt and How to Move to Cloud-Only, Petri IT Knowledgebase (Dean Ellerby).

Chi gestisce ambienti SQL Server on-premises conosce bene il problema: la migrazione verso il cloud richiede quasi sempre di mettere insieme tool diversi per la valutazione, il trasferimento dei dati, il monitoraggio e infine il cutover. Ogni fase ha strumenti propri, competenze diverse e margini di errore che si sommano. Con l’annuncio della disponibilità generale (GA) della migrazione a SQL Server su macchine virtuali Azure tramite Azure Arc, Microsoft porta l’intero ciclo di vita della migrazione dentro un’unica esperienza guidata nel portale Azure, lo stesso modello già usato per le migrazioni verso Azure SQL Managed Instance.

Per chi amministra data center misti, con carichi legacy e SQL Server sparsi su fisico e virtuale, questa novità merita attenzione: non è solo un annuncio di marketing, ma un cambio concreto di flusso di lavoro operativo.

Cos’è cambiato con la GAFino a poco tempo fa, chi voleva spostare un’istanza SQL Server su una VM Azure doveva combinare Azure Migrate, Database Migration Service e strumenti di backup/restore manuali, gestendo ciascuno con logiche e dashboard separate. Con la funzionalità di migrazione integrata in Azure Arc, il processo si consolida in quattro fasi accessibili da un singolo pannello, il Database Migration, associato all’istanza SQL Server abilitata da Arc:

Assess source instance — valutazione di leggibilità e readiness dell’istanza sorgente

Select target — scelta o creazione della VM SQL Server di destinazione

Migrate data — trasferimento effettivo dei database

Monitor and cutover — monitoraggio della sincronizzazione e passaggio finale in produzione

La discovery delle istanze e la generazione dei report di readiness avvengono automaticamente ogni fine settimana, ma possono essere lanciate anche manualmente, senza configurazioni aggiuntive: la funzione è disponibile di default per tutte le istanze SQL Server abilitate da Arc a partire da SQL Server 2012 (11.x).

Copilot integrato nel flusso di migrazioneUna parte interessante della nuova esperienza è l’integrazione di Microsoft Copilot direttamente nel pannello di migrazione. Non si tratta di un chatbot generico: interroga la knowledge base Microsoft nel contesto specifico della vostra migrazione e risponde a richieste operative come:

Come vengono eseguite le valutazioni?
Aiutami a confrontare le opzioni di destinazione
Avvia la migrazione
Aiutami a scegliere il metodo di migrazione corretto
Monitora la migrazione in corso
Completa la migrazionePer un DBA che gestisce decine di istanze, questo significa poter chiedere direttamente nel pannello “quale VM SKU è consigliata per questo carico?” invece di andare a cercare tabelle di sizing nella documentazione.

Come funziona la migrazione via backup e restoreIl meccanismo sotto il cofano non è nuovo per chi ha familiarità con le migrazioni SQL Server classiche: si basa su backup e restore con log shipping continuo, pensato per supportare scenari di migrazione online con downtime minimo.

Viene eseguito un backup completo del database sorgente

Il backup viene caricato su un account di Azure Blob Storage intermedio

Il backup viene ripristinato sull’istanza SQL Server target sulla VM Azure

I backup dei log delle transazioni vengono caricati in continuo sullo stesso storage e applicati automaticamente al database target, mantenendolo sincronizzato

Al momento del cutover, Azure Arc applica l’ultimo backup caricato e porta online il database target

Un vincolo operativo da tenere a mente in fase di progettazione: l’account di Azure Blob Storage e la VM SQL Server target devono trovarsi nella stessa region Azure. È un dettaglio facile da trascurare se si pianifica la migrazione partendo dalla region “storica” dell’organizzazione invece che da quella scelta per il nuovo carico.

Prerequisiti praticiUna subscription Azure attiva

L’istanza SQL Server deve essere abilitata da Azure Arc con l’estensione più recente installata (l’estensione si aggiorna indipendentemente da SQL Server, quindi va controllata separatamente)

L’ambiente sorgente preparato secondo le linee guida ufficiali, incluso l’upload iniziale dei backup nello storage account

Per verificare rapidamente la versione dell’istanza sorgente prima di avviare l’assessment, un semplice controllo T-SQL è sempre un buon punto di partenza:

SELECT SERVERPROPERTY('ProductVersion') AS Versione,
SERVERPROPERTY('Edition') AS Edizione,
SERVERPROPERTY('EngineEdition') AS TipoMotore;Cosa considerare prima di partireIl pannello di monitoraggio e cutover mostra in tempo reale quali database sono migrati con successo, quali sono ancora in corso, il metodo di migrazione scelto, la durata della sincronizzazione e i log dettagliati. Quando lo stato passa a “Ready for cutover”, si può decidere il momento esatto del passaggio in produzione selezionando Cutover, con opzioni diverse in base al metodo di migrazione utilizzato.

Va detto che, come per ogni migrazione basata su backup/restore, restano da valutare a parte gli aspetti di sizing della VM di destinazione (storage, IOPS, memoria per il buffer pool), la licenza SQL Server (Hybrid Benefit se applicabile) e la strategia di alta disponibilità post-migrazione, che questo strumento non copre direttamente ma per cui l’assessment fornisce indicazioni.

ConclusionePortare discovery, assessment, migrazione e monitoraggio in un’unica dashboard riduce sensibilmente l’attrito operativo delle migrazioni SQL Server verso Azure, soprattutto per i team che gestiscono ambienti ibridi complessi con decine o centinaia di istanze. Non elimina la necessità di pianificazione — region, sizing e licensing restano decisioni da prendere a monte — ma consolida in un solo posto ciò che prima richiedeva più tool scollegati tra loro. Per chi ha già istanze abilitate da Azure Arc, vale la pena aggiornare l’estensione e lanciare un primo assessment anche solo per farsi un’idea della readiness del proprio parco macchine.

Fonte: Petri IT Knowledgebase e documentazione Microsoft Learn.

Intune, Win32 app e detection rule: quale file version guarda davvero https://gioxx.org/2026/07/17/intune-detection-rule-win32app

#intune #lavoro #microsoft #microsoftwindows #powershell

Alternative a Fogli Google

Vediamo insieme un po’ di alternative molto valide ed open source a Fogli Google e ovviamente anche a Excel del pacchetto Microsoft Office!

https://blog.lealternative.net/2022/05/04/alternative-a-fogli-google/