netzpolitik.org

2026-08-12 06:09:05

Bundesdigitalminister Karsten Wildberger ist überzeugt, dass die hauseigene KI-Software „Spark Workflow“ Verwaltungsprozesse deutlich beschleunigen wird. Doch noch seien etliche Fragen offen, die auch der Minister nicht beantworte, sagt Digitalexperte Stefan @stk Kaufmann. Er plädiert für einen alternativen Ansatz, um die Verwaltung zu modernisieren.

netzpolitik.org/2026/ki-sprach…

„Das sind Annahmen, die sich schwer belegen lassen“

^{Esther Menhard (netzpolitik.org)}

(in)sicurezza digitale

2026-08-11 12:22:18

Tczew sotto attacco (di nuovo): dentro la campagna filorussa che sabota le centrali polacche

Il 10 agosto una turbina idroelettrica nei pressi di Danzica ha iniziato a impazzire: giri al minuto e potenza generata hanno oscillato in modo erratico fino all’arresto forzato del gruppo generatore-rotore. Non un guasto meccanico, ma la seconda intrusione andata a segno in pochi mesi contro lo stesso impianto, rivendicata con tanto di video dagli stessi attaccanti. È l’ultimo episodio di una campagna che il CERT Polska descrive ormai come sistematica contro il settore energetico e idrico del Paese, e che affonda le radici in un attacco ben più ampio, condotto a fine dicembre 2025 dal gruppo APT russo Sandworm contro una trentina di siti tra centrali di cogenerazione e centri di dispacciamento rinnovabili.

Un impianto già colpito, questa volta a pieno regime

La centrale presa di mira si trova a Tczew, nel voivodato della Pomerania, ed era già stata bersaglio di un primo tentativo a maggio 2026, fallito perché l’impianto era offline per manutenzione e l’impatto operativo fu quindi nullo. Il 10 agosto, invece, gli attaccanti sono riusciti a operare mentre la centrale era pienamente funzionante: la prima volta, secondo gli analisti polacchi, che questo specifico gruppo di hacktivisti filo-russi ottiene un’interferenza reale sui parametri di produzione. Una volta dentro l’interfaccia di controllo, hanno spinto i valori operativi ai loro estremi — minimo o massimo — fino a costringere generatore e rotore all’arresto. I dati di monitoraggio del giorno dell’attacco mostrano picchi anomali di velocità di rotazione e livello dell’acqua, alternati a periodi di potenza erogata pari a zero: la firma tipica di una manipolazione manuale del pannello SCADA, non di un errore di processo.

Gli stessi autori hanno pubblicato un video dell’intrusione, un dettaglio che negli ambienti di cybercrime filorusso serve tanto a rivendicare la paternità dell’attacco quanto a intimidire altri operatori del settore. L’attribuzione a un attore specifico resta fluida: gruppi come Cyber Army of Russia Reborn e la galassia riconducibile a Sandworm operano spesso in una zona grigia tra hacktivismo spontaneo e operazioni orchestrate dai servizi militari russi (GRU), rendendo la distinzione tra “protesta” e sabotaggio di stato sempre più teorica.

Il precedente: come un router in un parco eolico ha aperto la porta a un impianto di teleriscaldamento

Per capire la portata della minaccia occorre guardare a un report pubblicato in contemporanea dal CERT Polska, che ricostruisce nel dettaglio un secondo attacco avvenuto in parallelo a quello di fine dicembre 2025 contro il settore energetico polacco, fino ad ora meno noto. Il bersaglio era un piccolo impianto di cogenerazione (CHP) che fornisce calore a circa 50.000 residenti. L’obiettivo, scrive il CERT, era “puramente distruttivo”.

La catena di intrusione è particolarmente istruttiva perché introduce una tecnica mai documentata prima in Polonia né altrove: il pivoting attraverso una APN privata (Access Point Name), la rete cellulare dedicata che i distributori di energia (DSO) usano per far comunicare i propri sistemi SCADA con gli apparati di campo installati nelle sottostazioni.

• Accesso iniziale tramite un dispositivo Fortinet VPN/firewall esposto su internet e installato presso un parco eolico.
• Dalla stessa rete, individuazione di un router cellulare Teltonika e accesso alla sua interfaccia di amministrazione.
• Abuso del servizio SSH del router per creare un tunnel verso la APN privata gestita dal DSO, normalmente riservata al traffico SCADA legittimo.
• Scansione della APN e individuazione di un PLC Wago attivo presso l’impianto CHP, anch’esso con SSH esposto: da qui, accesso diretto alla rete OT della centrale.
• Dopo circa una settimana di ricognizione, connessione ai PLC Siemens, passaggio in modalità “stop” e impostazione di una password per impedire agli operatori di riprendere il controllo della logica di processo — con conseguente arresto della turbina a vapore e del sistema di trattamento acque.
• Presi di mira anche server seriali e switch di rete Moxa, oltre a inverter/VFD ABB e Schneider Electric, configurati per bloccare l’accesso agli operatori legittimi.

Il personale dell’impianto è riuscito a limitare i tempi di fermo ripristinando i PLC alle impostazioni di fabbrica e ricaricando la logica dai backup. Ma non tutto è stato recuperabile: nel tentativo di cancellare le tracce, gli attaccanti hanno danneggiato in modo permanente il controller Wago usato come gateway d’accesso, corrompendone la tabella delle partizioni. Un successivo reset di fabbrica non è bastato a farlo ripartire, e il dispositivo è rimasto inutilizzabile — portando con sé anche i log necessari all’indagine forense.

DynoWiper e il contesto dell’attacco del dicembre 2025

L’attacco alla APN privata va letto come parte della stessa ondata che il 29-30 dicembre 2025 colpì una trentina di siti energetici polacchi, incluse centrali di cogenerazione e centri di dispacciamento eolico e fotovoltaico. In quel caso ESET ha attribuito con confidenza media l’operazione a Sandworm, individuando l’uso di un nuovo wiper — battezzato DynoWiper e rilevato dai prodotti ESET come Win32/KillFiles.NMO — con tattiche molto simili al wiper ZOV già usato contro l’Ucraina. L’accesso iniziale in quel caso è avvenuto tramite dispositivi edge esposti su internet, seguito dalla distruzione di dati sulle interfacce HMI e dalla corruzione del firmware di alcuni apparati OT, causando danni permanenti ad alcune RTU (Remote Terminal Unit). L’operazione, va detto, è stata contenuta prima di provocare un blackout reale, e la tempistica — a ridosso del decimo anniversario dell’attacco alla rete elettrica ucraina del dicembre 2015 — non sembra casuale.

Il quadro complessivo che emerge da Tczew, dalla APN privata e da DynoWiper è quello di una pressione costante e multiforme sulle infrastrutture critiche polacche. Il vicepremier Krzysztof Gawkowski ha dichiarato che il Paese subisce oggi circa 300 attacchi al giorno di matrice russa, il triplo rispetto all’anno precedente, e che gli obiettivi spaziano dalla rete idrica a quella elettrica. Solo negli ultimi mesi sono stati colpiti impianti di trattamento acque a Szczytno, Sierakowo, Witków e il depuratore di Kuźnica, oltre a piscine e fontane pubbliche — bersagli minori ma sintomatici di una strategia che punta a normalizzare l’intrusione in qualunque sistema OT raggiungibile, non solo nei nodi strategici. Un pattern che ricorda da vicino quanto osservato in Norvegia, dove hacker filorussi hanno manipolato le valvole di una diga, e negli Stati Uniti e in Francia, dove impianti idrici sono stati presi di mira con le stesse modalità opportunistiche.

Due righe per i difensori

Il filo conduttore tra i due episodi polacchi è la superficie di attacco “dimenticata”: dispositivi edge esposti (VPN/firewall Fortinet), router cellulari con interfacce di amministrazione raggiungibili, servizi SSH lasciati attivi su PLC e gateway pensati per reti “isolate” ma di fatto raggiungibili tramite APN condivise con altri operatori. Per chi gestisce ambienti OT/ICS, in particolare nel settore energetico e idrico, questo caso offre alcune lezioni operative concrete: segmentare rigorosamente le APN private evitando che un singolo dispositivo compromesso funga da ponte tra reti di operatori diversi; disabilitare SSH e altri servizi di gestione remota sui PLC quando non strettamente necessari, o quantomeno restringerne l’accesso con allowlist IP e MFA; monitorare le interfacce HMI/SCADA per variazioni anomale dei parametri operativi che non corrispondono a comandi degli operatori; e predisporre backup offline della logica PLC, testati periodicamente, dato che in entrambi i casi documentati sono stati proprio i backup a permettere un ripristino rapido.

Indicatori e riferimenti tecnici

Malware: DynoWiper (ESET: Win32/KillFiles.NMO)
SHA-1 noto: 4EC3C90846AF6B79EE1A5188EEFA3FD21F6D4CF6
Attore: Sandworm (Russia, GRU-linked) - confidenza media
Vettore 1: dispositivi edge esposti (VPN/firewall Fortinet) - attacco 30 siti, dic. 2025
Vettore 2 (novel): pivot su APN privata via router cellulare Teltonika -> PLC Wago -> PLC Siemens (stop mode)
Apparati OT coinvolti: PLC Wago e Siemens, switch/serial server Moxa, VFD ABB/Schneider Electric
Impianto colpito 10 ago 2026: centrale idroelettrica di Tczew (Pomerania, Polonia)
Fonte primaria: report CERT Polska, follow-up settore energetico 2025

Nessun blackout è stato causato finora da queste operazioni, ma il trend è inequivocabile: gli attaccanti stanno affinando tecniche di pivoting sempre più sofisticate per raggiungere reti OT considerate “air gapped” o comunque isolate, e la loro pazienza — settimane di ricognizione silenziosa prima di agire — dimostra un livello di preparazione che va ben oltre il semplice defacement dimostrativo.

(in)sicurezza digitale

2026-08-11 12:21:10

StormEncryptor: come l’ex affiliato Medusa Storm-1175 ha trasformato N-central in un launchpad ransomware

Un singolo server compromesso, migliaia di endpoint amministrati a cascata: è lo scenario da incubo che si è materializzato dal 1° agosto 2026, quando un attore legato alla Cina e già noto per l’affiliazione al ransomware Medusa ha iniziato a sfruttare una vulnerabilità critica in N-central, la piattaforma di remote monitoring and management (RMM) di N-able usata da migliaia di managed service provider in tutto il mondo. Microsoft Threat Intelligence attribuisce la campagna al gruppo Storm-1175, che ha debuttato con un ceppo ransomware inedito, StormEncryptor, segnando un cambio di strategia rispetto al passato.

Da Medusa a StormEncryptor: chi è Storm-1175

Storm-1175 è il nome con cui Microsoft traccia un attore finanziariamente motivato, ritenuto basato in Cina, specializzato in campagne ransomware “ad alta velocità”. Già ad aprile 2026 Microsoft aveva descritto il gruppo come capace di passare dall’accesso iniziale alla cifratura completa dei sistemi in meno di 24 ore, sfruttando sia vulnerabilità appena divulgate sia, in alcuni casi, zero-day exploitati fino a una settimana prima della disclosure pubblica. Le vittime storiche del gruppo, colpite tramite il ransomware Medusa, includono organizzazioni sanitarie, di servizi professionali e finanziarie in Australia, Regno Unito e Stati Uniti, spesso raggiunte tramite lo sfruttamento di prodotti esposti su internet come GoAnywhere MFT, SmarterMail, Microsoft Exchange, Ivanti Connect Secure e JetBrains TeamCity.

Il 2 agosto 2026 Microsoft ha osservato per la prima volta il dispiegamento di StormEncryptor, un nuovo ransomware scritto in C++ che aggiunge l’estensione .encrypted ai file cifrati e deposita in ogni cartella una nota di riscatto denominata “!!!README_FIRST!!!.txt”, con la consueta minaccia di pubblicazione dei dati rubati entro tre giorni in caso di mancato pagamento. Si tratta della prima attività osservata del gruppo dopo un periodo di silenzio dall’aprile 2026, e il tempismo — lo stesso giorno della divulgazione della falla in N-central — non lascia molti dubbi sul vettore di accesso iniziale.

CVE-2026-18577: un bypass di autenticazione con “poteri da dio”

Il cuore tecnico della vicenda è CVE-2026-18577, una vulnerabilità di bypass dell’autenticazione in N-central che consente a un attaccante privo di qualsiasi credenziale di ottenere il controllo amministrativo completo del server. Si tratta, in realtà, di un bypass della patch che a sua volta correggeva un’altra falla, CVE-2026-18556: gli attaccanti hanno cioè trovato una variante capace di eludere i controlli introdotti dalla prima correzione. Huntress ha definito l’accesso ottenibile tramite questa falla un vero e proprio “god-mode access”: poiché gli MSP utilizzano N-central per amministrare da remoto le macchine dei propri clienti, la compromissione di un singolo server RMM diventa la porta d’ingresso verso ogni endpoint da esso gestito, con un potenziale effetto a cascata su decine di organizzazioni contemporaneamente. Non è un caso isolato nel suo genere: nel 2021 un attacco simile alla piattaforma RMM di Kaseya permise alla gang REvil di colpire inizialmente 60 clienti diretti e, a cascata, circa 1.500 aziende a valle; nel 2024 un episodio analogo coinvolse ConnectWise ScreenConnect, con Storm-1175 tra gli attori che ne approfittarono.

N-able ha individuato lo sfruttamento della falla per la prima volta il 31 luglio 2026, grazie alla soluzione MDR Adlumin, e ha rilasciato un primo hotfix (versione 2026.3.1.7) il 2 agosto. Non è bastato: gli attaccanti hanno trovato un modo per aggirare anche questa prima mitigazione, costringendo il vendor a pubblicare un secondo hotfix di emergenza (2026.3.1.10) il 6 agosto, con l’avvertenza esplicita che la prima patch da sola non fosse sufficiente. Nonostante la disponibilità delle correzioni, Huntress ha rilevato che oltre la metà dei server N-central cloud raggiungibili tra i propri partner risultava ancora non aggiornata, con il 28,6% delle istanze self-hosted ancora esposte.

La catena post-exploitation

Una volta ottenuto l’accesso amministrativo a N-central, gli attaccanti sfruttano la funzionalità legittima “Take Control” per collegarsi agli endpoint gestiti e registrano un nuovo servizio per un tunnel Cloudflare, garantendosi persistenza. Sophos, che ha ampliato l’elenco di indicatori di compromissione condiviso inizialmente da N-able, ha osservato la creazione di un nuovo account di dominio chiamato “veeam” — probabilmente scelto per mimetizzarsi tra gli account di servizio legittimi legati ai backup — oltre al reset delle password di diversi account amministratore di dominio esistenti, l’enumerazione di altri account e la disattivazione delle soluzioni di sicurezza Microsoft e Sophos tramite uno strumento di EDR-evasion.

Secondo l’analisi condivisa da Microsoft, il comportamento post-compromissione di Storm-1175 in questa campagna include l’abuso di strumenti RMM legittimi come AnyDesk e SimpleHelp, l’uso di Advanced IP Scanner per la ricognizione della rete e il dump delle credenziali LSASS tramite Mimikatz — un playbook che privilegia strumenti “living off the land” e software di amministrazione remota già presenti o facilmente installabili, per confondersi con il traffico amministrativo legittimo generato dallo stesso N-central. Huntress, che ha osservato lo sfruttamento su ambienti di propri clienti, conferma che gli attaccanti si muovono rapidamente attraverso più host all’interno delle organizzazioni colpite, prendendo di mira in particolare i domain controller.

Implicazioni per MSP e clienti a valle

Il numero esatto di organizzazioni colpite non è stato reso pubblico: N-able ha dichiarato di aver contattato un “numero limitato” di clienti interessati, mentre Huntress ha confermato impatti su propri clienti senza quantificarli. Ma la dinamica stessa dell’attacco — un fornitore RMM come singolo punto di fallimento per centinaia di aziende a valle — richiama da vicino Kaseya e ScreenConnect, e ribadisce un problema strutturale della filiera IT: la concentrazione di privilegi amministrativi in strumenti di gestione remota rende ogni MSP un moltiplicatore di rischio per l’intero proprio portafoglio clienti. Per chi utilizza N-central la priorità è immediata: applicare l’hotfix 2 (versione 2026.3.1.10), anche se è già stato applicato l’hotfix 1, e aggiornare gli agent sugli endpoint gestiti. Huntress raccomanda inoltre di valutare, per ambienti ad alto rischio dove l’esposizione non può essere ridotta in altro modo, la disattivazione temporanea di N-central, pur riconoscendo che ciò comporta la perdita di visibilità centralizzata, patching e accesso remoto proprio nel momento in cui potrebbero servire di più. Per i clienti finali degli MSP, la lezione è altrettanto rilevante: vale la pena chiedere al proprio fornitore quali strumenti RMM utilizza, se sono stati aggiornati, e quali controlli di segmentazione esistono tra l’infrastruttura di gestione e gli ambienti di produzione.

Indicatori di compromissione

Vulnerabilità sfruttata:
CVE-2026-18577 (bypass di autenticazione in N-able N-central,
  bypass della patch per CVE-2026-18556)

Ransomware:
StormEncryptor (C++, prima osservazione: 2 agosto 2026)
Estensione file cifrati: .encrypted
Nota di riscatto: !!!README_FIRST!!!.txt

Attore:
Storm-1175 (ex operatore/affiliato Medusa ransomware, presunta origine Cina)

Timeline:
31 luglio 2026 - N-able (Adlumin MDR) rileva sfruttamento zero-day
2 agosto 2026  - Hotfix 1 (N-central 2026.3.1.7) + prima StormEncryptor
6 agosto 2026  - Hotfix 2 (N-central 2026.3.1.10), il primo hotfix
                 risulta insufficiente

Tecniche post-exploitation osservate:
Abuso della funzione "Take Control" di N-central
Nuovo servizio per tunnel Cloudflare (persistenza)
Creazione account di dominio "veeam"
Reset password account amministratore di dominio
Disattivazione EDR Microsoft/Sophos tramite tool di evasione
Abuso di AnyDesk / SimpleHelp
Ricognizione con Advanced IP Scanner
Dump credenziali LSASS via Mimikatz

Precedenti storici affini:
2021 - Kaseya VSA / REvil (~1.500 aziende a valle)
2024 - ConnectWise ScreenConnect (Storm-1175 tra gli attori coinvolti)

Spcnet.it

2026-08-11 11:47:23

Microsoft Sentinel: le Detections-as-Code portano il GitOps nel SOC

Il SOC incontra il GitOps

Con 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 versionato

Microsoft 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 consigliata

Microsoft 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 è cambiato

Una 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 KQL

La 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 dati

L’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 ora

Per 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.

Microsoft Sentinel Expands Detections-As-Code and Data Visibility Features

Microsoft Sentinel's July 2026 update introduces detections-as-code workflows, Table Insights visibility, and new data connectors.

^{Rabia Noureen (Petri IT Knowledgebase)}

Spcnet.it

2026-08-11 11:45:27

Entra ID: l’operatore MemberOf va in pensione il 3 novembre 2026, ecco come prepararsi

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 memberOf

In 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 ritira

Durante 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 2026

Le 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 deadline

Il 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, MembershipRule

Per 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 migrazione

Una 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.

Conclusione

Il 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.

Microsoft to Retire Entra ID MemberOf Rule Operator

Microsoft will soon retire the Entra ID MemberOf rule operator, requiring organizations to update dynamic groups and entitlement policies.

^{Rabia Noureen (Petri IT Knowledgebase)}