Scalare: gestire paginazione, throttling e audit su tenant di grandi dimensioni in M365

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Scaling Up: Managing Pagination, Throttling, and Large Tenant M365 Audits

Bentornati sul blog! Se gestisci un tenant Microsoft 365 di grandi dimensioni, sai già che gli strumenti di reportistica standard non vanno oltre la superficie. Quando i team di sicurezza e i responsabili della conformità analizzano tenant enormi, gli script di base e le viste predefinite dell'interfaccia di amministrazione non reggono il peso di migliaia di utenti, gruppi e file. Verificare i tenant Microsoft 365 di grandi dimensioni richiede più di semplici script: serve un approccio tattico e programmatico basato sulla Microsoft Graph API. In questa guida approfondita riprendiamo e ampliamo la conversazione del nostro recente episodio del podcast "Map Microsoft 365 Users, Groups, Files, and Shares with Graph". Vediamo nel dettaglio come gestire la paginazione tramite @odata.nextLink, rispettare i limiti di richiesta 429 con backoff esponenziale ed evitare trappole comuni come il Page 1 bias, per ottenere una visibilità completa sull'intero tenant.

Introduzione alle sfide dell'audit in M365

Gli ambienti aziendali crescono in modo organico. Gli utenti arrivano e se ne vanno, i progetti fanno nascere interi reparti dall'oggi al domani e i fornitori esterni vengono invitati negli spazi di collaborazione. Col tempo la visibilità amministrativa si degrada: le interfacce di amministrazione predefinite mostrano frammenti isolati dell'infrastruttura, lasciando punti ciechi che attori malevoli o collaboratori interni distratti possono sfruttare. Per avere un quadro reale della postura di sicurezza del tenant, occorre passare dall'audit manuale, fatto di clic, a una navigazione automatizzata del grafo tramite API. Tuttavia, portare queste query su scala enterprise introduce ostacoli complessi, tra cui payload di dati enormi, throttling aggressivo e strutture relazionali profondamente annidate.

Perché M365 non è isolato: capire l'accesso relazionale

Una delle realtà fondamentali di Microsoft 365 è che servizi come SharePoint, Teams e OneDrive non sono silos isolati. Si scambiano continuamente informazioni tramite l'appartenenza ai gruppi e le liste di controllo accessi sottostanti. Una singola azione amministrativa, come aggiungere un utente a un gruppo di sicurezza, può propagarsi a decine di siti di team, librerie documentali e canali privati senza lasciare una traccia di audit evidente nelle viste standard.

Questo crea rischi di compliance nascosti. Link di condivisione ospite creati in chat isolate, file replicati in librerie di team diversi e condivisioni orfane di progetti ormai chiusi aprono percorsi invisibili verso i tuoi dati aziendali. In M365 l'accesso è intrinsecamente relazionale, non basato sulla posizione. Per fare un audit efficace devi mappare queste relazioni a cascata, invece di trattare ogni servizio come un'isola indipendente.

Mappatura delle attività con Graph Explorer

Prima di scrivere automazioni su scala enterprise, devi capire come tracciare manualmente le attività di un utente usando Graph Explorer. Costruire le query passo dopo passo assicura che la logica sia corretta prima di scrivere righe di codice. Ecco il percorso per mappare i punti di contatto di un utente:

Parti dall'utente: recupera l'oggetto utente principale con GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName.
Elenca le appartenenze: recupera i gruppi e i ruoli associati a quell'identità con GET /v1.0/users/{id}/memberOf?$select=id,displayName.
Risali alle risorse dei gruppi: per i gruppi Microsoft 365 e i team, individua il sito SharePoint sottostante con GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl, oppure elenca direttamente le unità del sito con GET /v1.0/sites/{siteId}/drives.
Verifica autorizzazioni e link degli elementi: controlla l'accesso ai singoli file con GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId.
Ricostruisci chi ha acceduto a cosa: correla le azioni degli utenti usando i log di accesso o gli avvisi di sicurezza insieme al contesto di file e siti.
Chiudi il cerchio con i post di Teams: cerca i riferimenti a file specifici nei messaggi dei canali con GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename" (tenendo presenti le autorizzazioni e i requisiti della versione beta).

Filtri per eliminare il rumore che userai davvero

Interrogare Microsoft Graph senza filtri significa travolgere rapidamente il sistema con un flusso di dati ingestibile. Per far emergere i rischi reali servono strategie di filtraggio precise. Ecco i pattern di query che dovresti adottare:

Condivisioni esterne negli ultimi 7 giorni: punta ai link anonimi o a livello di organizzazione usando GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' or link/scope eq 'organization'.
Solo i tipi di file a rischio: aggiungi filtri come $filter=endsWith(resourceReference/name,'.xlsm') oppure endsWith(resourceReference/name,'.pst') per intercettare macro e archivi.
Menzioni di termini sensibili fuori orario in Teams: cerca nei messaggi dei canali termini come confidential, poi filtra i risultati in base ai timestamp di creazione al di fuori dell'orario lavorativo normale.
Mantieni i payload leggeri: includi sempre i parametri $select per restituire solo gli identificatori, i nomi, gli URL e i timestamp necessari.
Limite per il triage: usa $top=50 per i controlli rapidi a campione, ma rimuovi questo parametro quando esegui esportazioni complete verso il tuo data store.

Requisiti indispensabili su scala enterprise: paginazione e throttling

Quando esegui audit su un tenant con centinaia di migliaia di oggetti, i tuoi script si scontreranno con dei muri se non tengono conto dei limiti delle API e della paginazione. Non hai mai finito di recuperare i dati finché non segui la proprietà @odata.nextLink per ogni singola pagina restituita dall'API. Ignorarla significa che i tuoi script acquisiranno solo il primo blocco di risultati, perdendo completamente il resto del tuo tenant.

Inoltre, devi rispettare le risposte HTTP 429 di limitazione della frequenza. Implementa una logica di backoff esponenziale robusta, in modo che lo script si fermi, attenda la fine del periodo di raffreddamento e riprenda senza interruzioni dal punto in cui si era fermato. Raggruppa le richieste con criterio, privilegiando poche richieste logiche più grandi, e memorizza in cache le mappature tra gruppi e siti. Per i tenant molto grandi, suddividi le scansioni per sito o intervallo di date e pianificale durante le ore di minor carico, per evitare di compromettere le prestazioni di produzione.

Errori comuni e soluzioni rapide

Anche gli amministratori più esperti incontrano ostacoli quando scalano gli audit di M365. Ecco gli errori più comuni e come risolverli:

Errore: le esportazioni CSV si disallineano man mano che gli schemi cambiano nel tempo. Soluzione: usa direttamente l'API Graph con trasformazioni versionate e gestisci con eleganza i campi sconosciuti.
Errore: identificatori misti come GUID e User Principal Name compromettono i join nei database. Soluzione: normalizza tutto in un modello semantico pulito che comprenda Utenti, Gruppi, Siti, Drive, Elementi e Autorizzazioni.
Errore: il bias della prima pagina nasconde la maggior parte degli incidenti di sicurezza che si trovano più in profondità nei risultati. Soluzione: registra sempre il numero totale di pagine elaborate e configura avvisi se il volume di dati previsto cala improvvisamente.
Errore: una valanga di file irrilevanti rallenta i motori di elaborazione. Soluzione: applica filtri rigorosi per ambiti di condivisione, finestre temporali ed elenchi di termini sensibili.
Errore: le condivisioni di Teams sono scollegate dai file sottostanti. Soluzione: correla gli URL web dei messaggi dei canali direttamente agli elementi del drive e memorizza entrambi gli identificatori insieme.

KPI a livello esecutivo che rendi possibili

I dati tecnici hanno valore solo se puoi tradurli in business intelligence utilizzabile per la dirigenza. Costruire una pipeline automatizzata di audit con Graph apre la strada a potenti KPI esecutivi:

Velocità di esposizione esterna: misura i nuovi link per ospiti creati ogni settimana, suddivisi per sito e team.
Tasso di accesso a file sensibili: monitora gli utenti unici che visualizzano contenuti etichettati, separando gli utenti interni dagli ospiti esterni.
Effetto domino sui gruppi: misura i file resi accessibili di recente entro 24 ore da importanti modifiche all'appartenenza ai gruppi.
Circolazione occulta: monitora i file sensibili che compaiono in più team o siti all'interno di un singolo sprint.
Efficacia della bonifica: tieni traccia nel tempo del numero di link revocati e delle metriche sul tempo di risoluzione.

Ricetta rapida per iniziare

Se sei pronto a costruire la tua pipeline di raccolta dati, usa questo flusso da copiare e incollare per iniziare subito:

Recupera i dettagli principali degli utenti e le relative appartenenze: /users/{upn}?$select=id,displayName e /users/{id}/memberOf?$select=id,displayName.
Per ogni gruppo Microsoft 365, elenca gli elementi del drive: /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200, assicurandoti di seguire @odata.nextLink.
Per ogni elemento, recupera le autorizzazioni: /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link, filtrando per ambiti anonimi o di organizzazione.
Esporta le righe nel tuo data store di riferimento, acquisendo ora del tenant, ID dei siti, ID dei drive, ID degli elementi, URL web, proprietari, ambiti e dettagli sulla scadenza.
Visualizza i dati normalizzati in Power BI per dashboard esecutive e operative.

Trasformare tutto questo in una dashboard sempre aggiornata

Un audit eseguito una volta sola è un'istantanea; un audit eseguito in modo continuo è un programma di sicurezza. Per trasformare le chiamate Graph grezze in una dashboard dinamica, carica i dati in Power Dataflows per ottenere tabelle normalizzate per Utenti, Gruppi, Siti, Unità, Elementi, Autorizzazioni e Messaggi. Modella i dati con uno schema a stella, con Elementi al centro e relazioni chiare verso Utenti e Gruppi.

Configura gli aggiornamenti incrementali in base ai campi lastModifiedDateTime, con aggiornamenti infragiornalieri per i siti ad alto rischio. Infine, imposta avvisi automatici che si attivino ogni volta che compaiono nuovi link esterni su contenuti con etichetta o quando picchi di group-ripple indicano un'estensione non autorizzata dell'accesso.

Piano di implementazione in 30 giorni

Roma non si costruì in un giorno, e un framework di audit aziendale richiede una pianificazione accurata. Segui questo piano di implementazione in 30 giorni per garantire un rollout senza intoppi:

Settimana 1: configura la registrazione dell'app in Azure, assegna le autorizzazioni Graph API con privilegi minimi e definisci le query di base usando i parametri $select e $filter.

Settimana 2: sviluppa gli script di paginazione, normalizza gli identificatori in UPN e nomi dei dispositivi coerenti ed esegui la prima esportazione dei dati completa end-to-end.

Settimana 3: crea il modello dati in Power BI e configura gli indicatori chiave di prestazione come l'esposizione esterna, il rischio ripple e i tempi che intercorrono tra accesso e revoca (dwell-to-revoke).

Settimana 4: automatizza gli aggiornamenti dei dati, implementa avvisi sulle anomalie e documenta le procedure operative standard per il team di indagine sulla sicurezza.

A chi è rivolto

Questo framework è pensato specificamente per gli amministratori di Microsoft 365 e i responsabili SecOps che sospettano che le dashboard verdi nascondano zone grigie, per i team di conformità che necessitano di una visibilità completa sulle condivisioni senza una proliferazione di strumenti di terze parti, e per i responsabili della collaborazione che devono garantire pratiche di condivisione esterna sicure.

Consigli pratici dal campo

Quando distribuisci questi script in un ambiente reale, tieni a mente questi consigli rapidi: inizia sempre le indagini dall'utente o dal file, quindi procedi in entrambe le direzioni per eliminare i punti ciechi. Considera ogni evento di aggiunta a un gruppo come una modifica ad alto rischio e verifica l'accesso derivato entro 24 ore. Mantieni un elenco aggiornato di termini sensibili da cercare nei nomi dei file e nei messaggi di Teams. Infine, registra con cura il numero di pagine e i volumi dei risultati: il silenzio di uno script è spesso il segno di un processo guasto, non di un tenant pulito.

Conclusione

Padroneggiare la paginazione, rispettare i limiti di frequenza ed evitare il bias della prima pagina sono competenze essenziali per chiunque debba proteggere un tenant Microsoft 365 di grandi dimensioni. Andando oltre le console di amministrazione di base e sfruttando appieno la potenza programmatica della Microsoft Graph API, puoi trasformare i rischi di condivisione invisibili in indicatori di sicurezza chiari e misurabili.

Per approfondimenti, esempi di codice e ricette Graph reali, ascolta la nostra discussione completa nel podcast. Scopri l'episodio correlato e tutti i dettagli su Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Resta al sicuro, continua ad automatizzare e ci vediamo nel prossimo episodio!