Cloud forensics: Google, Microsoft, Dropbox e backup

Introduzione

La cloud forensics riguarda l’acquisizione, la conservazione, l’analisi e la correlazione di dati custoditi o elaborati attraverso servizi cloud.

In una perizia informatica a Roma, il termine può riferirsi a sistemi molto differenti:

• Microsoft 365;
• Microsoft Entra ID;
• Exchange Online;
• OneDrive;
• SharePoint;
• Teams;
• Google Workspace;
• Gmail;
• Google Drive;
• Google Chat;
• Google Vault;
• Dropbox;
• iCloud;
• servizi SaaS;
• backup cloud;
• piattaforme di collaborazione;
• infrastrutture IaaS e PaaS.

Un file nel cloud non è semplicemente un file collocato su un disco remoto.

Può essere associato a:

- un identificativo stabile;
- una o più versioni;
- un proprietario;
- una cartella logica;
- un sito;
- un team;
- un tenant;
- un account;
- una condivisione;
- un link;
- autorizzazioni;
- commenti;
- attività;
- cestini;
- retention;
- hold;
- copie di backup;
- applicazioni collegate;
- dispositivi sincronizzati.

La domanda del cliente può essere:

oppure:

oppure:

oppure:

La risposta richiede di distinguere livelli differenti:

1. il contenuto visibile all’utente;
2. i metadati dell’oggetto cloud;
3. la cronologia delle versioni;
4. gli eventi di audit;
5. i dati presenti sul dispositivo sincronizzato;
6. gli elementi conservati per retention;
7. gli elementi sottoposti a hold;
8. le copie disponibili mediante backup;
9. i dati eventualmente detenuti dal provider;
10. gli elementi utili all’attribuzione personale.

La cloud forensics presenta una difficoltà strutturale: il perito non controlla direttamente il sistema che ha prodotto tutti i dati.

Una parte delle informazioni viene:

• visualizzata da un’interfaccia;
• restituita da un’API;
• esportata da uno strumento amministrativo;
• prodotta da un sistema eDiscovery;
• raccolta dal client locale;
• resa disponibile secondo il piano acquistato;
• conservata per un periodo definito dal provider o dall’organizzazione.

Il perito deve quindi documentare non soltanto che cosa ha acquisito, ma anche:

• da quale servizio;
• mediante quale account;
• con quali privilegi;
• attraverso quale funzione;
• con quale filtro;
• in quale formato;
• con quali limiti;
• in quale intervallo;
• in base a quale retention;
• dopo quali modifiche già eseguite.

Sintesi operativa

1. formalizzare incarico, titolarità e autorizzazioni;
2. identificare account personale, aziendale, tenant e provider;
3. documentare licenze, ruoli amministrativi e privilegi disponibili;
4. verificare subito audit retention, version history e cestini;
5. preservare gli account prima della cancellazione o disattivazione;
6. acquisire notifiche, sessioni, dispositivi e metodi di recupero;
7. evitare modifiche non documentate a password, condivisioni e policy;
8. predisporre, quando necessario, hold e procedure eDiscovery;
9. acquisire gli audit log nel formato più completo disponibile;
10. conservare le query e i filtri utilizzati;
11. segmentare gli export per evitare limiti o troncamenti;
12. acquisire identificativi stabili di file, utenti, siti e sessioni;
13. acquisire contenuti nativi, versioni e relativi metadati;
14. documentare cestino, cancellazioni e permanenti eliminazioni;
15. distinguere sync, version history, retention, hold e backup;
16. correlare il cloud con computer, smartphone, browser e rete;
17. analizzare OAuth, app collegate, token e account di servizio;
18. verificare link pubblici, guest ed utenti esterni;
19. calcolare l’hash di ogni export scaricato;
20. creare un manifesto degli allegati;
21. mantenere separati originali e copie di lavoro;
22. normalizzare le date conservando i timestamp originari;
23. documentare paginazione, errori e record mancanti;
24. costruire una timeline multipiattaforma;
25. distinguere account, sessione, dispositivo e persona fisica;
26. indicare sempre limiti di licenza, retention e indicizzazione;
27. proteggere dati personali, segreti e contenuti riservati;
28. produrre una relazione tecnica riproducibile.

1. Avvertenza preliminare

- password;
- codici OTP;
- seed phrase;
- chiavi private;
- cookie;
- token OAuth;
- codici di recupero;
- segreti applicativi;
- certificati con chiave privata;
- credenziali amministrative permanenti.

2. Che cos’è la cloud forensics

La cloud forensics applica i principi dell’informatica forense a sistemi in cui dati e funzioni sono distribuiti tra:

• provider;
• tenant;
• utenti;
• dispositivi;
• applicazioni;
• regioni;
• infrastrutture;
• sistemi di identità;
• API.

2.1 Acquisizione cloud

Raccolta di:

• audit log;
• file;
• email;
• chat;
• versioni;
• configurazioni;
• sessioni;
• utenti;
• autorizzazioni;
• dati amministrativi.

2.2 Endpoint forensics

Analisi dei dispositivi che hanno sincronizzato o consultato il servizio:

• computer;
• smartphone;
• tablet;
• browser;
• client desktop;
• cache;
• database locali.

2.3 Network forensics

Analisi di:

• DNS;
• proxy;
• firewall;
• VPN;
• indirizzi IP;
• user agent;
• traffico verso servizi cloud.

2.4 Identity forensics

Analisi di:

• account;
• MFA;
• OAuth;
• sessioni;
• dispositivi;
• service principal;
• app collegate;
• token;
• ruoli;
• account di servizio.

3. Perché il cloud non è un normale disco remoto

Nel cloud l’organizzazione logica può non coincidere con la struttura del file system.

Un documento può essere identificato da:

- drive ID;
- item ID;
- site ID;
- document ID;
- file ID;
- namespace ID;
- object ID;
- resource ID.

Il nome e il percorso possono cambiare senza modificare l’identificativo.

Esempio:

/Clienti/Contratto.docx
        ↓ rinomina
/Archivio/Contratto-definitivo.docx

Il provider può continuare a identificare l’oggetto mediante lo stesso file ID.

Questo è importante perché:

• il percorso può essere relativo all’utente;
• una cartella può essere montata in posizioni diverse;
• un file può essere condiviso senza essere duplicato;
• una copia può generare un nuovo ID;
• una rinomina può mantenere l’ID;
• una sincronizzazione può creare una copia locale distinta.

4. Modelli di servizio

4.1 SaaS

Il cliente utilizza un’applicazione gestita dal provider.

Esempi:

• Microsoft 365;
• Google Workspace;
• Dropbox;
• Salesforce;
• Slack.

Il cliente controlla soprattutto:

• identità;
• configurazioni;
• dati;
• ruoli;
• audit disponibili.

4.2 PaaS

Il cliente distribuisce applicazioni su una piattaforma gestita.

Può controllare:

• codice;
• configurazioni;
• log applicativi;
• database;
• identità.

4.3 IaaS

Il cliente gestisce maggiormente:

• macchine virtuali;
• dischi;
• reti;
• sistemi operativi;
• snapshot;
• security group;
• log.

Il modello di responsabilità determina quali dati possano essere acquisiti direttamente dall’organizzazione e quali dipendano dal provider.

5. Concetti da non confondere

Una funzione non sostituisce automaticamente le altre.

6. Sincronizzazione non significa backup

La sincronizzazione propaga normalmente le modifiche.

Se un file viene:

• cifrato;
• sovrascritto;
• rinominato;
• cancellato;

la modifica può essere sincronizzata sugli altri dispositivi.

La version history o il backup possono consentire il recupero, ma soltanto se:

• erano disponibili;
• coprivano il periodo;
• non sono stati eliminati;
• erano configurati correttamente;
• consentono il livello di ripristino necessario.

7. Retention non significa backup

Una retention policy può preservare contenuti per esigenze:

• normative;
• organizzative;
• probatorie;
• documentali.

Può però non fornire:

• ripristino rapido di interi account;
• recovery point frequenti;
• ricostruzione semplice dell’intero ambiente;
• isolamento da ogni privilegio amministrativo;
• conservazione dei log.

In Microsoft 365, retention policies e retention labels possono applicarsi a Exchange, SharePoint, OneDrive, gruppi Microsoft 365, Teams e altre posizioni; le label possono inoltre seguire il contenuto quando viene spostato all’interno del tenant e supportare funzioni aggiuntive come la classificazione come record. Microsoft Purview descrive tali differenze nella documentazione ufficiale.

8. Hold non significa export

Un hold serve a preservare dati rispetto alle normali operazioni di cancellazione.

Non produce automaticamente:

• un file scaricato;
• una copia locale;
• un hash;
• una relazione;
• una ricerca completa.

Occorre successivamente:

1. definire le fonti;
2. eseguire una ricerca;
3. verificare gli elementi non indicizzati;
4. produrre un export;
5. scaricarlo;
6. calcolare gli hash;
7. documentare le opzioni.

9. Backup non significa prova completa

Un backup può essere molto utile per:

• recuperare contenuti;
• confrontare stati;
• individuare versioni precedenti;
• documentare che un dato esisteva entro un certo momento.

Non dimostra automaticamente:

• chi abbia creato il file;
• chi lo abbia cancellato;
• chi lo abbia letto;
• la completezza degli audit;
• l’identità della persona;
• la liceità dell’azione.

10. Le domande tipiche del cliente

Un cliente di Roma può chiedere:

• chi ha cancellato un file;
• chi ha condiviso una cartella;
• chi ha scaricato documenti;
• se un ex dipendente abbia avuto accesso dopo le dimissioni;
• quando sia stato modificato un documento;
• se esistano versioni precedenti;
• se un account sia stato compromesso;
• quali messaggi siano conservati;
• se sia possibile recuperare elementi dal cestino;
• se un link fosse pubblico;
• se un file fosse stato scaricato anonimamente;
• se un backup sia utilizzabile;
• se il provider conservi dati eliminati;
• se sia possibile acquisire un account personale;
• se un audit log identifichi una persona.

La risposta deve separare:

- ciò che il servizio mostra;
- ciò che l’audit registra;
- ciò che è presente sull’endpoint;
- ciò che è stato preservato;
- ciò che può essere esportato;
- ciò che resta detenuto soltanto dal provider;
- ciò che non è più disponibile.

11. Livelli di attendibilità

Livello 1 — Interfaccia visualizzata

Esempi:

• data mostrata nella pagina;
• nome utente;
• contatore;
• schermata attività;
• elenco dispositivi.

È utile, ma dipende dalla rappresentazione del servizio.

Livello 2 — Export amministrativo

Esempi:

• CSV;
• JSON;
• PST;
• ZIP;
• report.

Aumenta la riproducibilità, ma può dipendere da filtri e limiti.

Livello 3 — Identificativi e record raw

Esempi:

• item ID;
• event ID;
• correlation ID;
• session ID;
• audit record originale.

Consentono correlazioni più robuste.

Livello 4 — Correlazione esterna

Il dato cloud viene correlato con:

• endpoint;
• browser;
• EDR;
• proxy;
• VPN;
• file locale;
• email;
• dispositivo mobile.

Livello 5 — Preservazione controllata

Il dato è:

• sottoposto a hold;
• esportato;
• sottoposto a hash;
• conservato secondo catena di custodia.

Livello 6 — Convergenza complessiva

Più fonti indipendenti supportano la stessa ricostruzione.

12. Inquadramento privacy

La cloud forensics può comportare il trattamento di:

• email;
• documenti;
• dati sanitari;
• dati giudiziari;
• informazioni finanziarie;
• conversazioni;
• dati di dipendenti;
• dati di clienti;
• segreti commerciali.

Il GDPR richiede, tra gli altri principi:

• finalità definite;
• minimizzazione;
• esattezza;
• limitazione della conservazione;
• sicurezza;
• responsabilizzazione.

L’acquisizione deve quindi essere limitata a ciò che è pertinente al quesito e protetta con misure adeguate. Il testo del Regolamento UE 2016/679 è disponibile su EUR-Lex.

12.1 Ruoli da coinvolgere

Secondo il caso:

• titolare del trattamento;
• DPO;
• legale;
• responsabile IT;
• responsabile sicurezza;
• HR;
• amministratore cloud;
• responsabile del trattamento.

12.2 Trasferimenti e data residency

Prima di scaricare grandi quantità di dati occorre verificare:

• ubicazione del tenant;
• destinazione dell’export;
• fornitori coinvolti;
• condizioni contrattuali;
• eventuali trasferimenti extra UE;
• cifratura;
• accessi.

13. Account personale e account aziendale

13.1 Account aziendale

L’organizzazione può generalmente amministrare il tenant secondo:

• contratto;
• ruoli;
• policy;
• normativa;
• informativa.

13.2 Account personale

L’organizzazione non acquisisce automaticamente il diritto di entrare nell’account perché:

• è stato usato da un dispositivo aziendale;
• contiene file aziendali;
• la password è salvata nel browser;
• una sessione è ancora attiva.

Dal computer aziendale possono essere acquisiti, se pertinenti e autorizzati:

• cronologia;
• cache;
• file locali;
• log proxy;
• eventi DLP;
• dati del client.

Non si deve utilizzare la sessione per esplorare contenuti personali senza titolo specifico.

13.3 Account misto

Alcuni account possono contenere sia dati personali sia aziendali.

È necessario:

• definire cartelle;
• intervalli;
• keyword;
• categorie;
• esclusioni;
• procedura di revisione.

14. Tenant, organizzazioni e domini

Identificare:

- tenant ID;
- primary domain;
- domini verificati;
- organizzazione;
- regione;
- piano;
- licenze;
- amministratori;
- account break-glass;
- identity provider;
- federazione.

Una stessa azienda può avere:

• più tenant;
• tenant di test;
• tenant acquisiti;
• domini storici;
• account guest;
• servizi non federati.

La mancata identificazione del tenant corretto può produrre un’acquisizione incompleta.

15. Utenti interni, guest ed esterni

Un’attività di un guest può essere registrata:

• nel tenant ospitante;
• nel tenant di origine;
• in entrambi;
• con dettaglio differente.

16. Volatilità dei dati cloud

I dati possono diventare indisponibili a causa di:

• scadenza dell’audit;
• cancellazione utente;
• rimozione della licenza;
• eliminazione definitiva;
• svuotamento del cestino;
• revoca di un link;
• chiusura del tenant;
• scadenza dell’export;
• modifica della retention;
• disattivazione dell’auditing;
• sovrascrittura della versione;
• rimozione dell’app.

La disponibilità deve essere verificata all’inizio dell’incarico.

17. Protocollo dei primi trenta minuti

1. identificare il provider e il tenant;
2. verificare chi possiede l’account;
3. nominare l’amministratore autorizzato;
4. registrare data, ora e UTC;
5. verificare la retention dei log;
6. preservare l’account;
7. evitare la cancellazione dell’utente;
8. acquisire sessioni e dispositivi;
9. acquisire ruoli e metodi MFA;
10. documentare condivisioni critiche;
11. esportare audit prossimi alla scadenza;
12. verificare cestini e versioni;
13. valutare un hold;
14. documentare licenze e privilegi;
15. aprire il registro del caso.

18. Protocollo delle prime ventiquattro ore

[ ] formalizzare il quesito;
[ ] creare la mappa delle fonti;
[ ] acquisire sign-in e audit log;
[ ] acquisire eventi amministrativi;
[ ] acquisire OAuth e applicazioni;
[ ] identificare account e dispositivi;
[ ] creare hold o preservation policy, se necessario;
[ ] esportare mailbox e file pertinenti;
[ ] scaricare versioni rilevanti;
[ ] acquisire cestini e deleted items;
[ ] preservare link e condivisioni;
[ ] acquisire endpoint sincronizzati;
[ ] acquisire proxy, firewall e VPN;
[ ] verificare eventuali backup;
[ ] calcolare gli hash;
[ ] costruire una timeline preliminare;
[ ] registrare limiti, errori e dati mancanti;
[ ] coinvolgere legale e DPO.

19. Cosa non fare

[ ] non cancellare l’utente prima della preservazione;
[ ] non modificare la retention senza documentarla;
[ ] non svuotare cestini;
[ ] non ripristinare versioni sugli originali prima dell’acquisizione;
[ ] non usare account sospetti per l’export;
[ ] non utilizzare privilegi superiori al necessario;
[ ] non eseguire export senza registrare i filtri;
[ ] non ignorare i limiti di paginazione;
[ ] non considerare il CSV completo per definizione;
[ ] non usare il cloud personale senza autorizzazione;
[ ] non trasmettere token al perito;
[ ] non modificare link e autorizzazioni prima di acquisirli;
[ ] non confondere sync e backup;
[ ] non concludere che l’assenza di audit escluda l’azione;
[ ] non attribuire un account a una persona senza ulteriori elementi.

20. Questionario iniziale

20.1 Servizio

1. Quale provider è coinvolto?
2. Account personale o aziendale?
3. Quale tenant?
4. Quale piano?
5. Quale licenza?
6. Quale regione?
7. Quali applicazioni?
8. Esistono backup esterni?
9. Esiste un SIEM?
10. Esiste eDiscovery o Vault?

20.2 Evento

1. Quale contenuto è contestato?
2. Quando è stato rilevato?
3. È stato cancellato?
4. È stato condiviso?
5. È stato scaricato?
6. È stato modificato?
7. Esiste un file ID?
8. Esiste un account sospetto?
9. Vi sono link esterni?
10. Vi sono dispositivi sincronizzati?

20.3 Azioni già eseguite

Chiedere se l’organizzazione ha:

• eliminato l’utente;
• rimosso la licenza;
• revocato sessioni;
• ripristinato file;
• modificato la retention;
• svuotato cestini;
• esportato dati;
• disattivato link;
• trasferito la proprietà;
• cambiato password;
• cancellato il client locale.

21. Definire il quesito tecnico

Quesito improprio:

Quesiti tecnici corretti:

- identificare i download associati all’account;
- individuare le versioni del documento;
- verificare chi abbia modificato la condivisione;
- acquisire gli eventi di cancellazione;
- verificare accessi da dispositivi non riconosciuti;
- acquisire i contenuti sottoposti a hold;
- correlare gli audit con il dispositivo;
- verificare la presenza del file nella cartella sincronizzata;
- documentare i limiti della retention;
- indicare quali dati non sono più disponibili.

22. Mappa delle fonti

22.1 Identità

• login;
• MFA;
• sessioni;
• dispositivi;
• ruoli;
• OAuth;
• token;
• service principal;
• account di servizio.

22.2 Contenuti

• email;
• file;
• chat;
• calendar;
• commenti;
• versioni;
• allegati;
• registrazioni;
• backup.

22.3 Audit

• attività utente;
• amministrazione;
• condivisioni;
• download;
• upload;
• eliminazioni;
• ricerca;
• export.

22.4 Endpoint

• client sync;
• browser;
• cache;
• file locali;
• EDR;
• log applicativi;
• database.

22.5 Rete

• VPN;
• proxy;
• DNS;
• firewall;
• CASB;
• DLP.

23. Cartella del caso

CASO_RM_2026_023/
├── 00_incarico/
├── 01_verbali/
├── 02_tenant_config/
├── 03_identita_sessioni/
├── 04_microsoft_entra/
├── 05_microsoft_purview/
├── 06_exchange/
├── 07_onedrive_sharepoint/
├── 08_teams/
├── 09_google_reports/
├── 10_google_vault/
├── 11_gmail_drive/
├── 12_dropbox/
├── 13_icloud/
├── 14_backup/
├── 15_endpoint/
├── 16_network/
├── 17_export_originali/
├── 18_hash/
├── 19_query/
├── 20_normalizzati/
├── 21_timeline/
├── 22_matrici/
├── 23_report/
└── 24_relazione/

24. Registro delle fonti

Annotare anche:

• timezone;
• query;
• numero record;
• pagine;
• errori;
• licenza;
• retention;
• sistema di origine;
• data dell’export.

25. Catena di custodia

Per ogni export registrare:

- identificativo;
- provider;
- tenant;
- account;
- ruolo;
- data e ora;
- workstation;
- browser o API;
- query;
- opzioni;
- nome file;
- dimensione;
- hash;
- destinazione;
- trasferimenti;
- accessi.

La metodologia generale è trattata nel Capitolo 2 — Catena di custodia, hash e verbale tecnico.

26. Calcolo dell’hash

PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\purview-audit.csv"

Linux

sha256sum -- purview-audit.csv

macOS

shasum -a 256 -- purview-audit.csv

Manifesto della directory

find export_originali -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > manifest_sha256.txt

L’hash documenta l’identità binaria dell’export scaricato.

Non dimostra:

• completezza dell’export;
• correttezza del provider;
• assenza di filtri;
• esistenza di dati ulteriori;
• autenticità precedente all’acquisizione.

27. Data, ora e fuso

Distinguere:

event time
ingest time
modification time
version time
deletion time
export time
download time
acquisition time

Registrare:

• timestamp originario;
• formato;
• offset;
• UTC;
• timezone dell’account;
• timezone della console;
• eventuale arrotondamento;
• precisione.

Molte API cloud utilizzano timestamp RFC 3339 o valori normalizzati in UTC.

Non convertire senza conservare l’originale.

28. Formato nativo e formato esportato

28.1 File nativo

Esempi:

• DOCX;
• XLSX;
• PDF;
• JPEG;
• EML;
• MSG.

28.2 File cloud-native

Esempi:

• Google Docs;
• Google Sheets;
• Google Slides;
• elementi collaborativi.

Un export può convertirli in:

• DOCX;
• XLSX;
• PPTX;
• PDF;
• HTML.

La conversione può modificare:

• hash;
• metadati;
• commenti;
• revisioni;
• rendering;
• funzioni;
• cronologia.

28.3 Regola

Conservare:

- identificativo cloud;
- formato originario logico;
- formato di export;
- opzioni;
- data;
- eventuali limitazioni.

29. Identificativi stabili

Preferire, quando disponibili:

- tenant ID;
- user ID;
- object ID;
- drive ID;
- site ID;
- item ID;
- file ID;
- message ID;
- thread ID;
- event ID;
- correlation ID;
- session ID.

I nomi possono cambiare.

Gli identificativi possono consentire di correlare:

• rinomina;
• spostamento;
• versione;
• condivisione;
• audit;
• endpoint.

30. Versioni, hash ed ETag

Una versione cloud può essere descritta mediante:

• version ID;
• modified time;
• modified by;
• size;
• ETag;
• hash;
• commento;
• stato.

30.1 ETag

Un ETag è un identificatore utilizzato dal servizio per la gestione della versione o della concorrenza.

Non deve essere trattato automaticamente come hash crittografico.

30.2 Hash del provider

Alcuni servizi espongono:

• SHA-1;
• SHA-256;
• QuickXorHash;
• content hash;
• revision ID.

Il significato dipende dal servizio.

30.3 Hash locale

Dopo il download, calcolare un hash locale sul file esportato.

31. Cancellazione e stati intermedi

Un contenuto può trovarsi in:

- attivo;
- spostato;
- cestino;
- deleted items;
- second-stage recycle bin;
- retained location;
- hold;
- backup;
- permanent deletion queue;
- definitivamente eliminato.

La parola “cancellato” deve quindi essere precisata.

32. Licenze e configurazione

Prima di concludere che un dato non esista, verificare:

• piano;
• licenza utente;
• licenza amministrativa;
• data di attivazione;
• auditing;
• retention;
• eDiscovery;
• Vault;
• backup;
• regione;
• servizio.

Un upgrade successivo non rende necessariamente disponibili dati già scaduti.

33. Principio del minimo privilegio

L’acquisizione dovrebbe utilizzare il ruolo meno invasivo che consenta l’attività.

Esempi:

• Reports Reader;
• Security Reader;
• Audit Reader;
• eDiscovery Manager;
• Vault privilege limitato;
• Dropbox report admin;
• account temporaneo.

Evitare l’impiego del Global Administrator quando non necessario.

Registrare:

• ruolo;
• data assegnazione;
• data revoca;
• attività;
• eventuali approvazioni.

34. Audit delle attività del perito

La stessa acquisizione può produrre nuovi log:

• login amministrativo;
• ricerca;
• preview;
• export;
• download;
• accesso al file;
• creazione hold;
• revoca sessione.

Questi eventi devono essere distinti dagli eventi oggetto dell’indagine.

35. Microsoft 365: mappa delle fonti

Microsoft Entra ID
├── sign-in logs
├── audit logs
├── risky users
├── MFA
├── service principals
└── app consent

Microsoft Purview
├── Audit
├── eDiscovery
├── retention
├── DLP
└── Insider Risk

Exchange Online
├── mailbox
├── rules
├── audit
├── message trace
└── deleted items

SharePoint / OneDrive
├── file
├── versioni
├── condivisioni
├── cestini
└── audit

Teams
├── chat
├── canali
├── file
├── registrazioni
└── meeting artifacts

Microsoft Purview eDiscovery può cercare, preservare ed esportare contenuti provenienti da Exchange Online, Teams, OneDrive, SharePoint, gruppi Microsoft 365 e altre fonti supportate. La documentazione ufficiale descrive l’ambito e le funzioni di eDiscovery.

36. Microsoft Entra ID: sign-in log

I sign-in log possono includere:

- createdDateTime;
- userPrincipalName;
- userId;
- appDisplayName;
- resourceDisplayName;
- ipAddress;
- clientAppUsed;
- deviceDetail;
- authenticationDetails;
- conditionalAccessStatus;
- correlationId;
- riskLevel;
- status.

36.1 Che cosa documentano

• tentativo;
• autenticazione;
• metodo;
• applicazione;
• IP;
• dispositivo dichiarato;
• esito.

36.2 Limiti

Non dimostrano automaticamente:

• chi controllasse le credenziali;
• quali file siano stati letti;
• la posizione fisica;
• l’intenzione;
• ogni attività svolta nella sessione.

37. Microsoft Graph: acquisizione dei sign-in

Per un amministratore autorizzato, Microsoft Graph espone gli eventi all’endpoint:

GET /auditLogs/signIns

La documentazione indica una pagina massima predefinita di 1.000 oggetti e raccomanda di filtrare per intervallo temporale; gli eventi disponibili restano comunque limitati alla retention applicabile del tenant. Riferimento Microsoft Graph per i sign-in.

PowerShell

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

Get-MgAuditLogSignIn `
  -Filter "createdDateTime ge 2026-07-01T00:00:00Z and createdDateTime le 2026-07-11T23:59:59Z" `
  -All |
  ConvertTo-Json -Depth 20 |
  Out-File ".\entra-signins.json" `
    -Encoding utf8

Registrare:

• versione modulo;
• account;
• scope;
• filtro;
• paginazione;
• errori;
• numero record;
• hash.

38. Microsoft Entra audit log

Può documentare:

• creazione account;
• cancellazione;
• reset password;
• modifica MFA;
• assegnazione ruolo;
• registrazione dispositivo;
• app consent;
• service principal;
• Conditional Access;
• gruppo;
• policy.

Correlare:

actor
→ target
→ operation
→ result
→ correlation ID
→ IP
→ timestamp

39. Retention degli audit Microsoft

Alla data di aggiornamento:

• Microsoft Purview Audit Standard conserva normalmente i record per 180 giorni;
• per utenti con licenze idonee, Audit Premium applica una policy predefinita di un anno per Exchange Online, SharePoint, OneDrive e Microsoft Entra;
• policy personalizzate possono estendere la conservazione fino a dieci anni con le licenze richieste;
• licenza, workload, utente e policy possono modificare la durata effettiva.

Le durate devono essere verificate nella documentazione e nel tenant. Microsoft descrive le audit log retention policies.

Non:

40. Microsoft Purview Audit

Purview Audit può includere eventi relativi a:

• Exchange;
• SharePoint;
• OneDrive;
• Teams;
• Entra;
• eDiscovery;
• DLP;
• amministrazione.

40.1 Acquisire

- query;
- utenti;
- operazioni;
- workload;
- intervallo;
- timezone;
- numero risultati;
- CSV;
- AuditData;
- errori.

40.2 Limiti

• risultati segmentati;
• licenza;
• retention;
• eventi non indicizzati;
• campi dipendenti dal workload;
• attività applicative non registrate;
• export troncato.

41. Search-UnifiedAuditLog

Esempio orientativo per amministratori autorizzati:

Connect-ExchangeOnline

Search-UnifiedAuditLog `
  -StartDate "2026-07-01T00:00:00" `
  -EndDate   "2026-07-11T23:59:59" `
  -UserIds   "utente@example.invalid" `
  -Operations `
    FileDownloaded,
    FileSyncDownloadedFull,
    FileUploaded,
    FileDeleted `
  -ResultSize 5000 |
  Export-Csv ".\purview-audit.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Per intervalli estesi:

- suddividere per giorno;
- suddividere per utente;
- suddividere per workload;
- controllare duplicati;
- confrontare il numero dei risultati;
- documentare i segmenti.

42. Purview eDiscovery

Un caso eDiscovery può contenere:

• data source;
• ricerche;
• hold;
• review set;
• export;
• membri;
• audit.

La piattaforma supporta la ricerca, la preservazione e l’esportazione di contenuti Microsoft 365; permessi come Search, Preview, Export e Hold devono essere assegnati secondo le attività necessarie. Microsoft descrive componenti e permessi di eDiscovery.

42.1 Procedura

1. creare il caso;
2. assegnare membri;
3. identificare le fonti;
4. creare il hold, se necessario;
5. definire la query;
6. esaminare statistiche ed errori;
7. verificare elementi parzialmente indicizzati;
8. produrre l’export;
9. scaricarlo;
10. calcolare gli hash.

43. Hold Microsoft

Un eDiscovery hold può preservare contenuti anche quando l’utente li modifica o li elimina dalla normale visualizzazione.

La creazione richiede:

• caso;
• policy;
• fonti;
• query;
• autorizzazioni;
• documentazione.

Microsoft permette di creare hold associati a un caso eDiscovery e di collegarvi le data source pertinenti. Procedura ufficiale per la creazione di un hold.

43.1 Attenzione

Un hold:

• non produce automaticamente un export;
• non rende ogni contenuto indicizzato;
• non sostituisce il backup;
• può avere impatto sulla conservazione;
• deve essere rimosso soltanto con autorizzazione.

44. Export Microsoft eDiscovery

Gli export possono includere:

• PST;
• messaggi individuali;
• documenti nativi;
• report;
• metadati;
• errori.

Microsoft indica che i risultati di Exchange possono essere esportati come PST o singoli messaggi, mentre SharePoint e OneDrive vengono esportati come copie dei documenti nativi; licenze, autorizzazioni e restrizioni DLP possono influire sull’export. Documentazione dell’export eDiscovery.

44.1 Conservare

- case ID;
- search ID;
- nome export;
- query;
- impostazioni;
- report;
- errori;
- data;
- download;
- hash.

45. Elementi parzialmente indicizzati

Un contenuto può non essere pienamente indicizzato a causa di:

• formato;
• cifratura;
• dimensione;
• errore;
• allegato;
• tipo non supportato.

Microsoft chiarisce che gli elementi parzialmente indicizzati possono richiedere opzioni dedicate durante la ricerca e l’export; una query per keyword può non trovare un termine presente soltanto nel corpo non indicizzato di un allegato. Approfondimento Microsoft sugli elementi parzialmente indicizzati.

46. Exchange Online

Fonti possibili:

• mailbox;
• online archive;
• Recoverable Items;
• deleted items;
• rules;
• forwarding;
• delegate;
• message trace;
• mailbox audit;
• Purview Audit;
• eDiscovery.

46.1 Acquisire

- messaggio originario;
- header;
- allegati;
- cartella;
- item ID;
- date;
- stato;
- regole;
- audit;
- eventuale hold.

L’analisi forense delle email e degli header deve essere coordinata con i dati del tenant.

47. Mailbox e messaggi eliminati

Distinguere:

Deleted Items
Recoverable Items
Purges
Versions
archive mailbox
retention copy
hold copy
backup copy

Il fatto che il messaggio non sia visibile nella cartella non dimostra che sia definitivamente eliminato.

La disponibilità dipende da:

• retention;
• hold;
• configurazione;
• data;
• licenza;
• stato della mailbox.

48. Teams

I dati Teams possono essere distribuiti tra:

• Exchange;
• SharePoint;
• OneDrive;
• registrazioni;
• servizi di meeting;
• audit.

Esempi:

chat:
componenti conservati nelle mailbox;

file del canale:
SharePoint;

file condiviso in chat:
OneDrive del mittente;

registrazioni:
OneDrive o SharePoint, secondo il contesto.

La fonte deve essere scelta in base al tipo di elemento, non alla sola interfaccia Teams. Microsoft eDiscovery aggrega le data source correlate a utenti, gruppi e team, includendo mailbox e siti SharePoint pertinenti. Documentazione sulle data source eDiscovery.

49. OneDrive e SharePoint

Acquisire:

• site ID;
• drive ID;
• item ID;
• percorso;
• proprietario;
• versioni;
• condivisioni;
• permessi;
• link;
• audit;
• cestino;
• retention.

49.1 Eventi utili

FileAccessed
FileDownloaded
FileSyncDownloadedFull
FileUploaded
FileSyncUploadedFull
FileModified
FileMoved
FileCopied
FileDeleted
SharingSet
AnonymousLinkCreated
SecureLinkCreated

Il nome esatto degli eventi e i campi devono essere verificati nella documentazione e nel tenant al momento dell’analisi.

50. Versioni OneDrive e SharePoint

OneDrive e SharePoint possono conservare una cronologia delle versioni secondo la configurazione applicata a organizzazione, sito, libreria o account.

Microsoft Graph consente di recuperare l’elenco delle versioni tramite endpoint come:

GET /sites/{site-id}/drive/items/{item-id}/versions

La disponibilità delle versioni dipende dalla configurazione del servizio e può essere differente tra posizioni. Riferimento Microsoft Graph per le versioni di DriveItem.

PowerShell con Microsoft Graph

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

$uri = "https://graph.microsoft.com/v1.0/sites/$SiteId/drive/items/$ItemId/versions"

Invoke-MgGraphRequest `
  -Method GET `
  -Uri $uri |
  ConvertTo-Json -Depth 20 |
  Out-File ".\item-versions.json" `
    -Encoding utf8

51. Cancellazione di un utente OneDrive

Alla data di aggiornamento, il periodo predefinito di retention del OneDrive appartenente a un utente eliminato è di 30 giorni, modificabile dall’amministrazione. Successivamente il sito può passare nel cestino della site collection per ulteriori 93 giorni; retention policy e hold possono prevalere sul normale processo di cancellazione. La documentazione avverte inoltre che il cestino non è indicizzato e che un hold eDiscovery non può individuare contenuto già presente soltanto nel cestino. Microsoft descrive il ciclo di retention e cancellazione di OneDrive.

Regola operativa

Prima di eliminare l’utente:

- preservare OneDrive;
- verificare manager e secondary owner;
- acquisire audit;
- valutare un hold;
- trasferire proprietà;
- esportare contenuti;
- documentare le policy.

52. Microsoft retention policy e label

Le retention policy possono applicarsi a intere posizioni.

Le retention label possono applicarsi al singolo elemento e seguirlo negli spostamenti interni supportati.

Acquisire:

• nome policy;
• scope;
• durata;
• azione finale;
• data applicazione;
• label;
• record status;
• eventuale event-based retention.

Non modificare le policy durante l’indagine senza registrare:

• autore;
• motivo;
• data;
• effetto;
• autorizzazione.

53. Microsoft 365 Backup

Alla data di aggiornamento, Microsoft 365 Backup protegge OneDrive, SharePoint ed Exchange Online con retention di un anno. La documentazione indica recovery point ogni dieci minuti per le due settimane più recenti e snapshot settimanali per il periodo successivo; il servizio utilizza storage append-only e mantiene le copie all’interno del perimetro Microsoft 365. Panoramica Microsoft 365 Backup.

53.1 Utilità forense

Può contribuire a:

• ripristinare uno stato;
• confrontare versioni;
• recuperare eliminazioni;
• ricostruire l’impatto di ransomware;
• verificare un intervallo.

53.2 Limiti

• deve essere stato attivato;
• protegge le fonti incluse nella policy;
• non sostituisce gli audit;
• non identifica l’autore;
• il ripristino può modificare l’ambiente;
• la retention è distinta da Purview.

53.3 Prima del restore

1. acquisire lo stato attuale;
2. documentare il restore point;
3. valutare restore in-place o alternativo;
4. registrare i contenuti coinvolti;
5. effettuare il restore;
6. acquisire il risultato;
7. confrontare gli stati.

54. Google Workspace: mappa delle fonti

Google Admin
├── login audit
├── admin audit
├── Drive audit
├── OAuth token audit
├── mobile audit
└── alert center

Google Vault
├── matters
├── holds
├── saved queries
├── search
├── exports
└── audit trail

Gmail
├── messaggi
├── header
├── allegati
├── forwarding
└── routing

Google Drive
├── file
├── revisioni
├── condivisioni
├── shared drives
├── cestino
└── activity

Google Vault supporta, secondo licenza e servizio, retention, hold, ricerca ed export per Gmail, Drive, Groups, Chat, Calendar, Meet, Sites, Voice e altri dati Workspace; alcune categorie richiedono condizioni specifiche, come la cronologia attiva per determinati messaggi Chat. Servizi e dati supportati da Google Vault.

55. Google Workspace Reports API

La Reports API può restituire eventi relativi a:

• amministrazione;
• login;
• Drive;
• OAuth;
• dispositivi;
• servizi supportati.

Alla data di aggiornamento, il periodo massimo interrogabile per i report di attività è di 180 giorni. Riferimento Activities della Reports API.

55.1 Endpoint generale

GET /admin/reports/v1/activity/users/{userKey}/applications/{applicationName}

userKey può essere:

• email;
• ID utente;
• all.

Per un utente cancellato può essere necessario utilizzare l’ID stabile recuperato dalla Directory API. Documentazione dell’endpoint Activities.list.

56. Esempio Reports API autorizzata

Il token deve provenire da un flusso OAuth legittimo e da un account con privilegi adeguati.

curl -sS \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/drive?startTime=2026-07-01T00:00:00Z&endTime=2026-07-11T23:59:59Z" \
  > google-drive-activity.json

Registrare:

- progetto;
- client;
- scope;
- account;
- privilegi;
- richiesta;
- paginazione;
- nextPageToken;
- errori;
- hash.

57. Login audit Google

Può documentare:

• login riusciti;
• login falliti;
• challenge;
• sospensioni;
• cambi password;
• eventi di sicurezza;
• IP;
• utente;
• data.

Non dimostra automaticamente:

• chi controllasse le credenziali;
• la posizione fisica;
• quali file siano stati consultati.

Correlare con:

• dispositivo;
• browser;
• proxy;
• MFA;
• Drive audit;
• Gmail.

58. Drive audit

Gli eventi Drive possono documentare:

• visualizzazione;
• download;
• modifica;
• creazione;
• condivisione;
• cambio visibilità;
• cancellazione;
• spostamento;
• modifica del proprietario;
• attività su shared drive.

Google documenta gli eventi Drive disponibili e consente di recuperarli tramite Activities.list() con applicationName=drive. Appendice degli eventi Drive.

58.1 Dati utili

- actor;
- event name;
- document ID;
- owner;
- visibility;
- IP;
- timestamp;
- target;
- application;
- old value;
- new value.

59. OAuth Token audit

Può documentare:

• concessione di un token;
• revoca;
• app;
• client ID;
• scope;
• utente.

Un’app autorizzata può:

• leggere file;
• accedere a email;
• operare offline;
• agire senza un login interattivo contemporaneo.

Google Reports API comprende report dedicati agli eventi OAuth e all’accesso di terze parti ai dati Workspace. Panoramica della Reports API.

60. Admin audit Google

Può documentare:

• modifica utente;
• gruppo;
• impostazioni di sicurezza;
• policy;
• routing;
• delega;
• applicazione;
• configurazione.

Acquisire anche le attività degli amministratori che:

• creano hold;
• avviano export;
• modificano retention;
• trasferiscono dati;
• cancellano utenti.

61. Google Vault

Google Vault è uno strumento di information governance ed eDiscovery.

Un matter può contenere:

• ricerche salvate;
• hold;
• export;
• account autorizzati;
• audit trail.

Un account deve disporre dei privilegi Vault necessari e dell’accesso al matter. Guida ufficiale ai matter di Google Vault.

61.1 Stato del matter

• Open;
• Closed;
• Deleted.

Un matter eliminato rimane nel cestino di Vault per circa trenta giorni prima della cancellazione definitiva. Riferimento ai matter di Vault.

62. Hold Google Vault

Un hold impedisce la cancellazione definitiva dei dati coperti.

Può applicarsi a:

• account;
• unità organizzativa;
• Gmail;
• Drive;
• Groups;
• altri servizi supportati.

Google indica che i dati eliminati dall’utente mentre il hold è attivo restano preservati e possono essere ricercati ed esportati da un amministratore Vault autorizzato. Guida ai hold di Google Vault.

62.1 Drive hold

Può includere:

• account;
• unità organizzative;
• shared drives;
• Meet recordings;
• nuovi Google Sites.

I hold prevalgono sulle regole di retention applicabili. Documentazione del Drive hold.

63. Export Google Vault

Gli export Vault vengono creati all’interno di un matter e resi disponibili attraverso Google Cloud.

Alla data di aggiornamento:

• possono essere eseguiti fino a venti export simultanei per organizzazione;
• gli export restano disponibili per il download per quindici giorni;
• gli export ampi dovrebbero essere suddivisi per periodo, utente o fonte.

La documentazione Vault descrive limiti e ciclo degli export.

63.1 Procedura

1. creare o aprire il matter;
2. definire la fonte;
3. salvare la query;
4. verificare il conteggio;
5. creare l’export;
6. monitorarne lo stato;
7. scaricare tutti i file;
8. verificare manifesti ed errori;
9. calcolare gli hash;
10. conservare i metadati dell’export.

64. Ricerca Vault

La ricerca può dipendere da:

• servizio;
• indicizzazione;
• query;
• intervallo;
• account;
• unità organizzativa;
• shared drive;
• cronologia Chat.

Google Vault supporta operatori diversi in base al servizio e non tutti i servizi utilizzano le stesse condizioni di ricerca. Guida alla ricerca in Google Vault.

65. Gmail e Vault

Vault può preservare, cercare ed esportare:

• messaggi;
• allegati;
• header;
• account;
• date;
• thread.

L’indice di Gmail presenta limiti dimensionali; un messaggio può essere esportato integralmente anche quando soltanto parte del contenuto risulta indicizzato per la ricerca. Servizi e limiti Google Vault.

65.1 File Drive collegati

Un messaggio può contenere:

• allegato tradizionale;
• collegamento a Drive;
• file con autorizzazioni variabili.

Acquisire:

• email;
• link;
• file ID;
• versione;
• permessi;
• audit.

66. Google Drive e shared drive

Distinguere:

• My Drive;
• Shared Drive;
• file condiviso;
• shortcut;
• file esterno;
• link.

Un file in shared drive appartiene all’organizzazione del drive, non al singolo utente nello stesso modo di un file personale.

Acquisire:

- file ID;
- drive ID;
- proprietario;
- organizzatore;
- permessi;
- versione;
- attività;
- data.

67. Google Drive: cestino e recupero

Per gli account ordinari, i file nel cestino di Google Drive rimangono normalmente disponibili per trenta giorni prima della cancellazione automatica. Guida Google al recupero dei file eliminati.

Non concludere tuttavia che un file sia sempre recuperabile entro quel termine:

• può essere eliminato definitivamente;
• può appartenere a un altro proprietario;
• può essere soggetto a policy;
• può trovarsi in shared drive;
• può essere preservato da Vault;
• può essere stato trasferito.

68. Google Drive: version history

Drive consente di visualizzare attività e versioni, ma la semantica varia tra:

• file binari caricati;
• Google Docs;
• Sheets;
• Slides;
• cartelle;
• elementi cloud-native.

Google Drive consente inoltre, in specifiche funzioni, di ripristinare in blocco modifiche dei file a uno stato precedente; il ripristino modifica l’ambiente e dovrebbe quindi essere eseguito soltanto dopo aver acquisito lo stato attuale. Guida Google al ripristino delle modifiche.

69. Google Chat, Meet e Calendar

69.1 Chat

La preservazione dipende anche dalla configurazione della cronologia.

Messaggi con history off o contenuti in determinati spazi esterni possono non essere coperti nello stesso modo. Guida Vault ai hold per Chat.

69.2 Meet

Registrazioni e log associati possono essere trattati mediante Drive o regole Meet dedicate, secondo la configurazione Vault. Guida Vault ai dati Meet.

69.3 Calendar

Vault supporta retention, hold, ricerca ed export degli eventi Calendar nelle edizioni applicabili. Servizi supportati da Vault.

70. Export organizzativo e Takeout

Distinguere:

Google Vault

Orientato a:

• ricerca;
• preservation;
• eDiscovery;
• casi.

Data Export amministrativo

Orientato a:

• esportazione di dati organizzativi;
• migrazione;
• conservazione amministrativa.

Google Takeout

Orientato principalmente all’utente e alle categorie disponibili nel relativo account.

Nessuna delle procedure deve essere considerata automaticamente:

• completa di ogni audit;
• equivalente a un’immagine forense;
• comprensiva di dati definitivamente eliminati;
• sostitutiva di Vault.

71. Dropbox: mappa delle fonti

Dropbox account
├── sessioni
├── dispositivi
├── app collegate
└── sicurezza

Dropbox team
├── activity report
├── admin actions
├── sharing report
├── member activity
└── team_log API

Content
├── file ID
├── namespace
├── version history
├── deleted files
├── shared links
└── Rewind

72. Dropbox team activity

La console amministrativa Dropbox per team consente di produrre report sulle attività degli utenti.

Alla data di aggiornamento, il report può essere filtrato per:

• evento;
• membro;
• intervallo;
• contenuto;

ed esportato in CSV, con data, soggetto, attività e contenuto coinvolto. Guida Dropbox ai report amministrativi.

72.1 Limiti

La disponibilità di attività dettagliate dipende:

• dal piano;
• dal ruolo amministrativo;
• dal tipo di contenuto;
• dalla proprietà del file;
• dal periodo;
• dalla funzione utilizzata.

73. Dropbox team_log API

L’endpoint API:

team_log/get_events

restituisce eventi normalizzati che possono includere:

• timestamp;
• event category;
• event type;
• actor;
• context;
• origin;
• IP;
• host;
• access method;
• participants;
• assets;
• file ID;
• namespace.

Dropbox distingue l’attore dal contesto per conto del quale l’attività viene eseguita e raccomanda l’uso degli identificativi stabili degli asset invece del solo percorso. Guida Dropbox agli eventi e alla migrazione verso team_log.

Esempio autorizzato

curl -sS \
  -X POST \
  "https://api.dropboxapi.com/2/team_log/get_events" \
  -H "Authorization: Bearer ${DROPBOX_TEAM_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"limit":1000}' \
  > dropbox-team-events.json

Utilizzare soltanto token applicativi autorizzati.

Registrare:

• app;
• scope;
• admin;
• team ID;
• richiesta;
• cursor;
• paginazione;
• errori;
• hash.

74. Dropbox file ID e namespace

Un evento può includere:

• contextual path;
• namespace ID;
• namespace-relative path;
• file ID.

Il percorso contestuale può essere differente per utenti diversi.

Il file ID può rimanere stabile attraverso:

• rinomina;
• spostamento.

Per questo la correlazione dovrebbe privilegiare:

file ID
+
namespace ID
+
timestamp
+
actor

invece del solo nome.

75. Dropbox version history

Alla data di aggiornamento, Dropbox indica:

• 30 giorni per Basic, Plus e Family;
• 180 giorni per Professional, Essentials, Business e Standard;
• 365 giorni per Business Plus, Advanced ed Enterprise;
• eventuali estensioni attraverso add-on.

L’upgrade non estende retroattivamente la cronologia già scaduta. Panoramica Dropbox della version history.

75.1 Limiti

La version history:

• non ripristina elementi definitivamente eliminati;
• non si applica allo stesso modo a file web-based;
• dipende dal piano;
• non sostituisce l’audit;
• non identifica automaticamente l’autore.

76. Dropbox deleted files

I file eliminati restano recuperabili entro il periodo previsto dal piano, salvo cancellazione definitiva e altri limiti.

Prima del ripristino:

1. acquisire l’attività;
2. acquisire il file ID;
3. acquisire la versione corrente;
4. documentare il cestino;
5. eseguire il restore;
6. acquisire la versione ripristinata;
7. calcolare gli hash.

77. Dropbox Rewind

Dropbox Rewind consente di annullare in blocco modifiche apportate a file e cartelle ed è indicato anche per eventi di perdita massiva o ransomware. Guida ufficiale a Dropbox Rewind.

77.1 Precauzioni forensi

Prima del rewind:

• esportare il team activity;
• documentare la data scelta;
• acquisire campioni;
• preservare file cifrati;
• registrare chi esegue il rewind;
• acquisire l’esito.

Il rewind modifica numerosi oggetti e può influire su tutti i membri delle cartelle condivise.

78. Dropbox sharing

Acquisire:

• shared link;
• visibilità;
• password;
• scadenza;
• autore;
• destinatari;
• download;
• visualizzazioni;
• cartella;
• file ID.

La console amministrativa può generare report sulle condivisioni esterne; la pagina di attività ordinaria non mostra necessariamente ogni azione, per cui è opportuno produrre un report completo per l’intervallo pertinente. Guida Dropbox al monitoraggio delle condivisioni.

79. Dropbox Transfer

Dropbox Transfer può essere utilizzato per inviare file anche a destinatari privi di account Dropbox.

Per i piani e i ruoli supportati, gli amministratori possono visualizzare eventi come:

• transfer inviato;
• visualizzato;
• file aggiunto;
• download;
• eliminazione.

Guida Dropbox alla gestione dei Transfer del team.

Questo canale deve essere verificato quando non risultano normali condivisioni o link.

80. Dropbox offboarding

Prima di eliminare un membro:

- acquisire attività;
- preservare file;
- verificare dispositivi;
- verificare app;
- trasferire contenuti;
- revocare sessioni;
- documentare link.

Dropbox avverte che il trasferimento dei file di un membro eliminato deve avvenire entro il periodo coperto dalla version history applicabile. Guida Dropbox al trasferimento dell’account.

81. iCloud: particolarità forensi

iCloud può comprendere:

• Drive;
• Photos;
• Mail;
• Backup;
• Notes;
• Contacts;
• Calendars;
• Messages;
• Safari;
• dati applicativi.

L’accessibilità dipende da:

• account;
• dispositivo fidato;
• autenticazione;
• Advanced Data Protection;
• accesso web;
• chiavi;
• sincronizzazione;
• categoria.

82. Protezione standard e Advanced Data Protection

Advanced Data Protection estende la cifratura end-to-end a molte categorie iCloud, incluse Backup, Photos, Notes e iCloud Drive.

Quando è attiva, le chiavi per la maggior parte dei dati restano sui dispositivi fidati e Apple non dispone delle chiavi necessarie per decifrare tali categorie. Apple descrive le categorie protette e il modello di sicurezza iCloud.

82.1 Conseguenza forense

L’acquisizione può dipendere maggiormente da:

• dispositivo sbloccato;
• computer sincronizzato;
• backup locale;
• sessione autorizzata;
• recovery method.

Non è lecito né tecnicamente corretto promettere l’acquisizione provider-side di dati end-to-end encrypted.

83. Accesso web iCloud

Con Advanced Data Protection, l’accesso web ai dati iCloud viene disattivato automaticamente e deve essere temporaneamente autorizzato mediante un dispositivo fidato.

L’abilitazione dell’accesso web costituisce una modifica dell’account e deve essere documentata. Apple descrive la procedura di accesso web con ADP.

84. Apple Data and Privacy

Apple mette a disposizione strumenti per:

• ottenere una copia dei dati;
• trasferire categorie supportate;
• correggere informazioni;
• disattivare o eliminare l’account.

Nell’Unione europea sono disponibili anche richieste una tantum o ricorrenti per specifiche categorie. Guida Apple a Data and Privacy.

84.1 Procedura

1. documentare l’account;
2. selezionare le categorie;
3. acquisire la conferma;
4. attendere la preparazione;
5. scaricare tutti gli archivi;
6. conservare email e manifesti;
7. calcolare gli hash;
8. annotare categorie mancanti.

L’export non deve essere considerato equivalente a un’immagine completa del dispositivo.

85. Acquisizione di iCloud Drive e Photos

Apple consente di copiare i file iCloud Drive da dispositivo, Mac o iCloud.com e di esportare fotografie e video, anche come originali non modificati quando si utilizza la funzione appropriata. Alcuni elementi di album condivisi o trasferimenti verso altri servizi possono non conservare tutte le caratteristiche, come commenti, like o determinate varianti del file. Guida Apple alla copia dei dati iCloud.

85.1 Conservare

- file originale;
- sidecar;
- Live Photo;
- metadati;
- data;
- album;
- versione;
- modalità di export;
- hash.

86. Dispositivi Apple associati

Acquisire:

• elenco dispositivi;
• nome;
• modello;
• sistema;
• seriale disponibile;
• numeri fidati;
• notifiche;
• sessioni;
• data.

Apple raccomanda di verificare dispositivi, notifiche e informazioni dell’account in presenza di accessi sospetti. Indicazioni Apple per mantenere sicuro l’account.

Un dispositivo mostrato nell’account non dimostra automaticamente chi lo abbia materialmente utilizzato.

87. Provider-side data e dispositivo

Una ricostruzione iCloud può richiedere la combinazione di:

- export Apple;
- iCloud.com;
- Mac sincronizzato;
- iPhone o iPad;
- iCloud for Windows;
- backup locale;
- notifiche;
- email;
- account settings.

L’assenza di una categoria nell’export non dimostra necessariamente che non sia mai esistita sul dispositivo.

88. Endpoint sincronizzati

I dispositivi locali possono contenere:

• file completi;
• placeholder;
• database;
• cache;
• log;
• versioni;
• miniature;
• link;
• configurazioni;
• token protetti.

L’analisi forense del computer Windows, di macOS e Linux, di Android e di iPhone o iPad completa i dati del provider.

89. Placeholder e file on-demand

Un file visualizzato in una cartella sincronizzata può essere:

• disponibile offline;
• soltanto placeholder;
• parzialmente scaricato;
• presente nella cache;
• eliminato localmente;
• ancora disponibile nel cloud.

Non concludere:

senza verificare:

• dimensione;
• stato;
• attributi;
• contenuto;
• apertura;
• cache;
• hash.

90. OneDrive sul computer

Possibili artefatti:

• cartella sincronizzata;
• database client;
• log;
• registry;
• tenant;
• account;
• file on-demand;
• notification;
• processi;
• Prefetch;
• browser.

Correlare:

item cloud
→ item ID
→ percorso locale
→ stato sync
→ file content
→ audit

91. Google Drive for desktop

Può utilizzare:

• streaming;
• mirroring;
• cache;
• mount virtuale;
• cartelle locali.

Acquisire:

• account;
• modalità;
• drive montati;
• log;
• cache;
• database;
• file offline;
• processi;
• configurazioni.

Un elemento nella cache può essere:

• completo;
• parziale;
• temporaneo;
• relativo a una versione precedente.

92. Dropbox desktop

Possibili fonti:

• cartella Dropbox;
• database client;
• log;
• configurazioni;
• file offline;
• selective sync;
• online-only;
• processi;
• dispositivi.

La presenza di un file online-only non dimostra che il contenuto sia stato scaricato integralmente.

93. iCloud Drive su macOS e Windows

Verificare:

• cartelle locali;
• placeholder;
• download;
• Photos Library;
• iCloud for Windows;
• file recenti;
• Unified Log;
• account;
• processi;
• stato sync.

Su Mac, la sincronizzazione può interagire con:

• Finder;
• File Provider;
• Photos;
• Optimize Storage.

94. Browser forensics

Il browser può conservare:

• cronologia;
• download;
• upload;
• cookie;
• IndexedDB;
• local storage;
• service worker;
• cache;
• sessioni;
• OAuth redirect;
• notifiche.

94.1 Limiti

• modalità privata;
• pulizia;
• sincronizzazione;
• browser multipli;
• estensioni;
• attività API.

La presenza di un URL non dimostra necessariamente che il contenuto sia stato letto integralmente.

95. Proxy, firewall e DNS

Possono documentare:

• connessione;
• dominio;
• URL;
• quantità di dati;
• applicazione;
• user agent;
• upload;
• download.

Un volume di traffico non identifica automaticamente il file trasferito.

Correlare con:

• audit cloud;
• endpoint;
• timestamp;
• account;
• item ID;
• processo.

Vedere il Capitolo 20 — Analisi di log aziendali, firewall, VPN e sistemi cloud.

96. OAuth e app collegate

Un’app può accedere al cloud tramite token senza richiedere continuamente la password.

Acquisire:

- app;
- client ID;
- publisher;
- scope;
- data consenso;
- ultimo utilizzo;
- actor;
- tipo di token;
- revoca;
- audit.

96.1 Rischi

• consenso fraudolento;
• app eccessivamente privilegiata;
• token offline;
• service principal;
• account di servizio;
• integrazione dimenticata.

L’analisi degli accessi abusivi agli account deve includere la persistenza applicativa.

97. Token e sessioni

Una sessione cloud può sopravvivere:

• al cambio password;
• al riavvio;
• alla chiusura del browser;
• su dispositivi differenti.

Verificare:

• session revocation;
• token revocation;
• app consent;
• refresh token;
• dispositivi;
• MFA;
• account recovery.

98. Link anonimi

Un link anonimo può consentire l’accesso senza identità autenticata.

Acquisire:

• URL;
• file ID;
• creatore;
• data;
• scadenza;
• password;
• visibilità;
• download;
• disattivazione;
• audit.

98.1 Limite

Quando l’accesso è realmente anonimo, il provider può non disporre di un’identità utente verificata.

Possono restare:

• IP;
• user agent;
• data;
• evento;
• quantità.

99. Guest e collaborazione esterna

Verificare:

• invito;
• accettazione;
• tenant di origine;
• account;
• accesso;
• condivisione;
• gruppo;
• rimozione;
• sessione.

Un guest può aver:

• visualizzato;
• modificato;
• scaricato;
• condiviso ulteriormente;
• usato un’app.

La capacità di osservare le azioni dipende dal servizio.

100. Download manuale e sincronizzazione

Distinguere:

download browser:
azione esplicita tramite interfaccia;

sync download:
replica automatica o richiesta del client;

offline availability:
preparazione locale;

copy:
duplicazione interna al servizio;

export:
conversione o pacchetto prodotto dal servizio.

Un evento FileSyncDownloadedFull non deve essere descritto automaticamente come un download manuale.

101. Upload e modifica

Un upload può derivare da:

• browser;
• sync;
• app mobile;
• API;
• backup;
• importazione;
• copia interna.

Correlare:

• access method;
• client;
• IP;
• item ID;
• versione;
• file locale;
• processo.

102. Paginazione e limiti

Le API restituiscono spesso:

• page token;
• next link;
• cursor;
• continuation token.

Un export è completo soltanto se:

- tutte le pagine sono state scaricate;
- non vi sono errori;
- non vi sono limiti superati;
- l’intervallo è coperto;
- i record sono stati conteggiati;
- i token sono stati seguiti.

102.1 Registro di paginazione

Pagina:
Token:
Record:
Primo evento:
Ultimo evento:
Errore:
Hash:

103. Deduplicazione

Record duplicati possono derivare da:

• export sovrapposti;
• più pagine;
• retry;
• sorgenti differenti;
• sincronizzazione;
• eventi aggregati.

Non eliminare duplicati dagli originali.

Creare un dataset derivato usando:

provider
+ event ID
+ timestamp
+ actor
+ object ID
+ raw hash

104. Indicizzazione e ricerca

Una ricerca può non trovare un contenuto perché:

• non indicizzato;
• formato non supportato;
• allegato cifrato;
• keyword diversa;
• lingua;
• OCR assente;
• file cloud-native;
• data fuori intervallo;
• account errato;
• cestino non indicizzato;
• history disattivata.

105. Backup cloud: principi forensi

Un backup utile deve essere valutato rispetto a:

• ambito;
• frequenza;
• retention;
• isolamento;
• immutabilità;
• cifratura;
• ruoli;
• test;
• restore;
• logging.

105.1 Domande

1. Quali account erano protetti?
2. Da quando?
3. Quale frequenza?
4. Quale retention?
5. Chi poteva eliminare i backup?
6. Esiste un secondo amministratore?
7. Esistono alert sulle modifiche?
8. È stato testato il restore?
9. Il backup conserva versioni?
10. Conserva audit o solo contenuti?

106. Snapshot, version history e backup

Un ransomware può:

• cifrare i file sincronizzati;
• cancellare versioni;
• eliminare snapshot;
• modificare policy;
• compromettere backup.

La protezione deve quindi includere separazione dei privilegi e test di ripristino.

107. Backup di terze parti

Un’organizzazione può utilizzare un provider esterno per proteggere Microsoft 365, Google Workspace o altri SaaS.

Acquisire:

- contratto;
- scope;
- account protetti;
- data;
- restore point;
- storage region;
- cifratura;
- amministratori;
- audit;
- export;
- hash.

Il backup di terze parti non è automaticamente più completo di quello nativo.

Occorre verificare:

• API utilizzate;
• dati esclusi;
• chat;
• versioni;
• metadati;
• limiti;
• frequenza.

108. Ripristino forense

Prima di ripristinare:

1. acquisire lo stato attuale;
2. identificare il restore point;
3. documentare il contenuto;
4. scegliere destinazione alternativa, se possibile;
5. eseguire il restore;
6. acquisire il risultato;
7. confrontare versioni;
8. registrare gli eventi generati.

Il restore in-place può sovrascrivere o alterare lo stato contestato.

Per una perizia può essere preferibile:

• ripristino in cartella alternativa;
• tenant di test;
• sito alternativo;
• account controllato;
• copia di laboratorio.

109. Caso pratico 1 — Download massivo da OneDrive

Scenario

Un’azienda di Roma sospetta che un dirigente abbia scaricato file prima delle dimissioni.

Risultati

- account individuale;
- dispositivo gestito;
- eventi FileSyncDownloadedFull;
- client OneDrive configurato;
- 6.200 file sincronizzati;
- nessun upload esterno rilevato;
- laptop riconsegnato.

Conclusione

110. Caso pratico 2 — File eliminato da SharePoint

Scenario

Uno studio legale di Roma rileva la scomparsa di un documento.

Risultati

• item ID disponibile;
• evento di cancellazione;
• account guest;
• file nel cestino;
• versione precedente;
• accesso da IP aziendale del cliente.

Conclusione

111. Caso pratico 3 — OneDrive di un dipendente eliminato

Scenario

Un’azienda romana cancella l’account e cerca i file due mesi dopo.

Risultati

- periodo OneDrive configurato a 30 giorni;
- sito nel cestino della site collection;
- nessun hold preventivo;
- contenuti non individuabili dalla ricerca eDiscovery ordinaria;
- restore ancora tecnicamente disponibile.

Conclusione

112. Caso pratico 4 — Google Drive e link pubblico

Scenario

Una società romana scopre che una cartella era condivisa mediante link.

Risultati

• visibilità “chiunque abbia il link”;
• autore della condivisione;
• data;
• audit di modifica;
• nessun account per alcune visualizzazioni;
• link revocato dopo l’acquisizione.

Conclusione

113. Caso pratico 5 — Google Vault e messaggi eliminati

Scenario

Un’azienda di Roma deve acquisire email eliminate da un utente.

Risultati

- hold attivato prima della cancellazione;
- matter aperto;
- query per account e periodo;
- messaggi reperiti in Vault;
- export MBOX;
- report e hash.

Conclusione

114. Caso pratico 6 — Google audit scaduto

Scenario

Un cliente di Roma chiede di verificare un download avvenuto nove mesi prima.

Risultati

• Reports API limitata al periodo disponibile;
• nessun SIEM esterno;
• file ancora presente;
• endpoint originale non disponibile;
• nessun Vault audit pertinente.

Conclusione

115. Caso pratico 7 — Dropbox e ransomware

Scenario

Un ransomware cifra la cartella Dropbox di un’impresa romana.

Risultati

- version history attiva;
- client desktop compromesso;
- migliaia di file modificati;
- team activity acquisita;
- Rewind disponibile;
- copie dei file cifrati preservate.

Conclusione

116. Caso pratico 8 — Dropbox Transfer

Scenario

Un ex collaboratore invia un archivio tramite Dropbox Transfer.

Risultati

• evento di creazione transfer;
• file aggiunto;
• destinatario;
• download registrato;
• archivio non più disponibile;
• hash recuperato dall’endpoint.

Conclusione

117. Caso pratico 9 — iCloud con Advanced Data Protection

Scenario

Un cliente di Roma deve acquisire fotografie da un account protetto da ADP.

Risultati

• accesso web inizialmente disattivato;
• iPhone fidato disponibile;
• accesso temporaneamente autorizzato;
• originali esportati;
• Live Photo conservate;
• hash calcolati.

Conclusione

118. Caso pratico 10 — Sync non equivalente a sottrazione

Scenario

Un’azienda romana osserva 20.000 file scaricati dal client cloud sul nuovo laptop di un dipendente.

Risultati

• provisioning aziendale;
• dispositivo assegnato;
• sync iniziale automatica;
• ticket IT;
• nessun servizio esterno;
• nessun supporto rimovibile.

Conclusione

119. Caso pratico 11 — App OAuth compromessa

Scenario

Uno studio professionale di Roma rileva accessi ai file senza login interattivi anomali.

Risultati

- app OAuth autorizzata;
- permesso offline;
- accessi API;
- download;
- consenso concesso da account compromesso;
- token revocato.

Conclusione

120. Caso pratico 12 — Backup presente ma non attivo sul sito

Scenario

Un’azienda romana presume che tutti i siti SharePoint siano protetti da Microsoft 365 Backup.

Risultati

• policy attiva;
• soltanto alcuni siti inclusi;
• sito contestato escluso;
• version history disponibile;
• nessun restore point Backup.

Conclusione

121. Errori da evitare

1. Considerare il cloud un disco remoto. Si ignorano ID, versioni e condivisioni.
2. Conservare soltanto screenshot. Mancano record, campi e query.
3. Non acquisire gli ID stabili. Rinomine e spostamenti diventano difficili da correlare.
4. Confondere sync e backup. La cancellazione può propagarsi.
5. Confondere retention e backup. Hanno finalità differenti.
6. Confondere hold ed export. Il hold preserva, ma non scarica.
7. Confondere cestino e cancellazione definitiva. Sono stati differenti.
8. Non verificare la licenza. Audit e retention possono cambiare.
9. Aggiornare la licenza troppo tardi. I dati scaduti possono non tornare disponibili.
10. Eliminare l’utente prima della preservazione. Si avvia il processo di cancellazione.
11. Non verificare il OneDrive dell’utente eliminato. I termini possono essere brevi.
12. Ignorare il secondo cestino SharePoint. Può contenere ancora il sito o gli elementi.
13. Creare un hold dopo che il dato è soltanto nel cestino non indicizzato. Potrebbe non essere individuato dalla ricerca.
14. Non includere elementi parzialmente indicizzati. La ricerca può essere incompleta.
15. Considerare il CSV completo per definizione. Può essere troncato.
16. Non seguire la paginazione. Si perdono record.
17. Non conservare la query. L’acquisizione non è riproducibile.
18. Non registrare l’account amministrativo. Le attività del perito si confondono con quelle indagate.
19. Usare il Global Administrator senza necessità. Si amplia il rischio.
20. Non revocare i privilegi temporanei. Resta un accesso non necessario.
21. Non acquisire OAuth e app. L’attività può avvenire tramite token.
22. Cambiare soltanto la password. Sessioni e token possono restare validi.
23. Attribuire un IP a una persona. Può essere VPN, proxy o rete condivisa.
24. Fidarsi della geolocalizzazione. È approssimativa.
25. Attribuire l’account alla persona. Le credenziali possono essere condivise o compromesse.
26. Accedere al cloud personale del dipendente. Può essere non autorizzato.
27. Utilizzare cookie salvati per entrare nell’account. È un accesso distinto e potenzialmente illecito.
28. Ripristinare prima di acquisire. Si modifica lo stato contestato.
29. Eseguire Rewind senza preservare gli eventi. Si perde contesto.
30. Considerare una versione prova dell’autore. Indica una modifica associata a un account.
31. Confondere ETag e hash crittografico. Hanno funzioni differenti.
32. Ignorare i file cloud-native. L’export può convertirli.
33. Confrontare hash di formati convertiti. La conversione cambia il file.
34. Non documentare il formato di export. Si perde il significato della copia.
35. Non preservare manifesti ed error report. L’export può essere incompleto.
36. Considerare Vault l’intera mailbox. L’export dipende dalla query.
37. Ignorare la finestra di 15 giorni degli export Vault. Il pacchetto può diventare indisponibile.
38. Non verificare la cronologia Chat. Alcuni messaggi potrebbero non essere preservati.
39. Considerare il cestino Drive un archivio permanente. Ha durata limitata.
40. Ignorare shared drives. La proprietà differisce da My Drive.
41. Considerare il contextual path Dropbox univoco. Dipende dall’utente.
42. Non usare file ID e namespace Dropbox. Rinomine e spostamenti complicano l’analisi.
43. Considerare Dropbox Rewind un backup forense. È una funzione di ripristino.
44. Non verificare il piano Dropbox. La version history varia.
45. Presumere che iCloud.com sia sempre disponibile. ADP può disabilitarne l’accesso.
46. Disattivare ADP per comodità. Si modifica la protezione dell’account.
47. Non acquisire il dispositivo fidato. Può essere l’unica fonte delle chiavi.
48. Considerare l’export Apple completo del dispositivo. Sono fonti differenti.
49. Non analizzare gli endpoint sincronizzati. Il cloud audit può non mostrare ogni dettaglio locale.
50. Considerare il placeholder un file completo. Potrebbe non contenere i dati.
51. Non acquisire proxy e VPN. Manca la correlazione di rete.
52. Considerare un link anonimo attribuibile a ogni visitatore. Può mancare l’identità.
53. Non acquisire i guest. Le azioni possono provenire da account esterni.
54. Confondere download e sincronizzazione. La semantica operativa cambia.
55. Confondere evento e contenuto. Un audit può registrare l’azione senza includere il file.
56. Considerare assenza di audit come assenza dell’azione. La retention può essere scaduta.
57. Non verificare il backup effettivamente attivo. La sola licenza non protegge ogni account.
58. Considerare snapshot, versioni e backup equivalenti. Coprono scenari differenti.
59. Non testare il restore. La disponibilità nominale non garantisce il recupero.
60. Formulare conclusioni giuridiche. Il perito deve restare nell’ambito tecnico.

122. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] titolare;
[ ] tenant;
[ ] account;
[ ] incarico;
[ ] legale;
[ ] DPO;
[ ] perimetro;
[ ] periodo;
[ ] dati personali.

Fase 2 — Inventario

[ ] provider;
[ ] servizi;
[ ] licenze;
[ ] utenti;
[ ] guest;
[ ] app;
[ ] backup;
[ ] endpoint;
[ ] SIEM.

Fase 3 — Preservazione

[ ] account;
[ ] hold;
[ ] retention;
[ ] cestini;
[ ] versioni;
[ ] link;
[ ] mailbox;
[ ] backup.

Fase 4 — Identità

[ ] sign-in;
[ ] MFA;
[ ] sessioni;
[ ] dispositivi;
[ ] OAuth;
[ ] ruoli;
[ ] account di servizio;
[ ] token.

Fase 5 — Audit

[ ] utente;
[ ] amministrazione;
[ ] file;
[ ] condivisione;
[ ] download;
[ ] upload;
[ ] eliminazione;
[ ] export.

Fase 6 — Contenuti

[ ] file nativi;
[ ] email;
[ ] chat;
[ ] versioni;
[ ] metadati;
[ ] allegati;
[ ] commenti;
[ ] registrazioni.

Fase 7 — eDiscovery

[ ] caso;
[ ] membri;
[ ] fonti;
[ ] hold;
[ ] query;
[ ] errori;
[ ] export;
[ ] hash.

Fase 8 — Endpoint

[ ] computer;
[ ] smartphone;
[ ] browser;
[ ] sync client;
[ ] cache;
[ ] placeholder;
[ ] file locali;
[ ] EDR.

Fase 9 — Rete

[ ] IP;
[ ] VPN;
[ ] proxy;
[ ] firewall;
[ ] DNS;
[ ] CASB;
[ ] DLP.

Fase 10 — Backup

[ ] scope;
[ ] restore point;
[ ] retention;
[ ] immutabilità;
[ ] ruoli;
[ ] test;
[ ] restore alternativo.

Fase 11 — Normalizzazione

[ ] timestamp originale;
[ ] UTC;
[ ] actor;
[ ] sessione;
[ ] object ID;
[ ] event ID;
[ ] raw record;
[ ] source.

Fase 12 — Correlazione

[ ] cloud;
[ ] endpoint;
[ ] rete;
[ ] account;
[ ] dispositivo;
[ ] file;
[ ] versione;
[ ] persona.

Fase 13 — Relazione

[ ] materiale;
[ ] metodo;
[ ] query;
[ ] risultati;
[ ] timeline;
[ ] attribuzione;
[ ] lacune;
[ ] limiti;
[ ] allegati;
[ ] hash.

123. Checklist finale

Perimetro

[ ] tenant corretto;
[ ] account corretto;
[ ] periodo definito;
[ ] licenze documentate;
[ ] autorizzazioni documentate;
[ ] ruoli minimi.

Microsoft

[ ] Entra sign-in;
[ ] Entra audit;
[ ] Purview Audit;
[ ] eDiscovery;
[ ] Exchange;
[ ] OneDrive;
[ ] SharePoint;
[ ] Teams;
[ ] Backup.

Google

[ ] login audit;
[ ] Drive audit;
[ ] admin audit;
[ ] OAuth audit;
[ ] Vault matter;
[ ] hold;
[ ] export;
[ ] Gmail;
[ ] Drive.

Dropbox

[ ] activity report;
[ ] team log;
[ ] file ID;
[ ] namespace;
[ ] version history;
[ ] deleted files;
[ ] sharing;
[ ] Rewind.

iCloud

[ ] account;
[ ] dispositivi;
[ ] ADP;
[ ] accesso web;
[ ] Data and Privacy;
[ ] Drive;
[ ] Photos;
[ ] backup;
[ ] endpoint.

Conservazione

[ ] formato nativo;
[ ] query;
[ ] filtri;
[ ] paginazione;
[ ] report errori;
[ ] SHA-256;
[ ] manifesto;
[ ] originali separati.

Interpretazione

[ ] sync distinta dal backup;
[ ] retention distinta dal hold;
[ ] download distinto dalla sync;
[ ] account distinto dalla persona;
[ ] assenza distinta da indisponibilità;
[ ] limiti documentati.

124. Output minimo dell’accertamento

1. incarico;
2. verbale;
3. inventario provider e tenant;
4. registro delle fonti;
5. licenze e ruoli;
6. configurazioni retention;
7. configurazioni backup;
8. sign-in log;
9. audit log identità;
10. audit utente;
11. audit amministrativo;
12. audit file;
13. audit condivisioni;
14. OAuth e applicazioni;
15. sessioni e dispositivi;
16. hold;
17. matter o case;
18. query;
19. statistiche;
20. report errori;
21. export mailbox;
22. export file;
23. versioni;
24. cestini;
25. link;
26. condivisioni;
27. Microsoft Entra;
28. Purview;
29. Exchange;
30. OneDrive;
31. SharePoint;
32. Teams;
33. Microsoft 365 Backup;
34. Google Reports API;
35. Google Vault;
36. Gmail;
37. Drive;
38. Chat e Meet;
39. Dropbox team activity;
40. Dropbox API;
41. Dropbox version history;
42. iCloud export;
43. iCloud Drive;
44. iCloud Photos;
45. endpoint sincronizzati;
46. browser;
47. proxy e firewall;
48. manifesti SHA-256;
49. dataset normalizzato;
50. timeline;
51. matrice delle evidenze;
52. tabella delle lacune;
53. relazione tecnica;
54. allegati;
55. hash degli output.

125. Struttura della relazione tecnica

125.1 Incarico

• committente;
• quesito;
• titolarità;
• autorizzazione;
• periodo;
• limiti.

125.2 Architettura cloud

• provider;
• tenant;
• domini;
• servizi;
• identità;
• endpoint;
• backup.

125.3 Fonti

• audit;
• eDiscovery;
• file;
• mailbox;
• versioni;
• endpoint;
• rete.

125.4 Metodo

• ruoli;
• query;
• API;
• export;
• paginazione;
• hash;
• normalizzazione.

125.5 Risultati identità

• login;
• MFA;
• sessioni;
• dispositivi;
• app;
• token.

125.6 Risultati contenuti

• file;
• email;
• chat;
• versioni;
• cancellazioni;
• condivisioni.

125.7 Backup e recupero

• policy;
• restore point;
• test;
• risultato;
• limiti.

125.8 Timeline

• evento;
• fonte;
• timestamp;
• UTC;
• attendibilità;
• deduzione.

125.9 Attribuzione

• account;
• sessione;
• dispositivo;
• IP;
• persona;
• alternative.

125.10 Limiti

• retention;
• licenza;
• indicizzazione;
• dati eliminati;
• export;
• provider;
• account personale.

125.11 Conclusioni

Risposte tecniche proporzionate al quesito.

126. Modelli di frasi tecniche

126.1 Export cloud

126.2 Audit

126.3 Account

126.4 IP

126.5 Download

126.6 Sincronizzazione

126.7 File cloud-native

126.8 Versione

126.9 Hash

126.10 Cancellazione

126.11 Hold

126.12 Ricerca

126.13 Dato non reperito

126.14 Retention scaduta

126.15 Link anonimo

126.16 Guest

126.17 OAuth

126.18 Backup

126.19 Restore

126.20 iCloud ADP

126.21 Assenza di audit

126.22 Attribuzione personale

126.23 Limite generale

127. Immagini e figure suggerite

128. Riferimenti tecnici e normativi esterni

1. Microsoft Purview — Audit log retention policies, retention Standard, Premium e policy personalizzate.
2. Microsoft Purview — Retention policies e retention labels.
3. Microsoft Purview — eDiscovery, data source, hold ed export.
4. Microsoft Graph — Sign-in log di Microsoft Entra.
5. Microsoft Graph — Cronologia delle versioni OneDrive e SharePoint.
6. Microsoft — Retention e cancellazione di OneDrive per utenti eliminati.
7. Microsoft 365 Backup — Ambito, retention e recovery point.
8. Google Workspace Reports API — Attività e limite temporale degli audit.
9. Google Workspace — Eventi di audit Drive.
10. Google Vault — Matter, hold, ricerca ed export.
11. Google Vault — Servizi e tipologie di dati supportati.
12. Google Drive — Cestino, attività e versioni.
13. Dropbox — Report amministrativi e team activity.
14. Dropbox API — Team log, attori, contesto, origine e asset.
15. Dropbox — Version history e finestre di recupero.
16. Dropbox — Rewind e recupero di modifiche massive.
17. Apple — Sicurezza dei dati iCloud e Advanced Data Protection.
18. Apple — Accesso web ai dati iCloud con ADP.
19. Apple — Data and Privacy ed esportazione dei dati.
20. Regolamento UE 2016/679 — Principi e sicurezza del trattamento.

129. Collegamenti interni consigliati

Capitolo precedente

• Dipendente infedele, sottrazione dati e uso di USB

Capitolo successivo

• Autenticità audio: tagli, montaggi e ricodifiche

Capitoli correlati

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Incident response forense e ransomware
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

130. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/incident-response-forense/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

cloud forensics a Roma
perizia Microsoft 365
analisi Google Workspace
acquisizione forense di OneDrive
analisi SharePoint e Teams
perizia Google Drive
acquisizione Google Vault
analisi Dropbox forensics
verifica di file cancellati dal cloud
analisi delle versioni cloud
perizia su link e condivisioni
analisi dei backup cloud
ricostruzione degli accessi a un tenant
consulente informatico forense cloud a Roma

131. Box commerciale finale

Devi acquisire o ricostruire dati presenti nel cloud a Roma?

Lo Studio Quaranta Digital Forensics può supportare aziende, professionisti, privati, studi legali, responsabili IT e DPO nelle attività di:

[ ] acquisizione Microsoft Entra ID;
[ ] analisi Microsoft 365;
[ ] acquisizione Exchange Online;
[ ] analisi OneDrive e SharePoint;
[ ] acquisizione Teams;
[ ] Microsoft Purview Audit;
[ ] eDiscovery e hold;
[ ] analisi Google Workspace;
[ ] Google Vault;
[ ] Gmail e Google Drive;
[ ] Dropbox team activity;
[ ] analisi iCloud;
[ ] acquisizione delle versioni;
[ ] recupero controllato dei file;
[ ] analisi di link e condivisioni;
[ ] verifica dei backup;
[ ] correlazione con computer e smartphone;
[ ] timeline forense;
[ ] relazione tecnica;
[ ] assistenza al legale e al CTP.

CTA principale: Richiedi una valutazione preliminare
CTA secondaria: Descrivi il provider, l’account e il periodo da verificare

Lo Studio non garantisce:

• disponibilità dei dati;
• recupero di elementi definitivamente eliminati;
• completezza degli audit;
• identificazione della persona;
• accesso a dati cifrati end-to-end;
• esito di un procedimento.

132. Conclusione del capitolo

La cloud forensics non consiste nel premere il pulsante “Esporta”.

Una corretta attività deve documentare l’intera catena:

provider
→ tenant
→ identità
→ sessione
→ oggetto
→ versione
→ attività
→ retention
→ export
→ hash
→ correlazione
→ relazione

La qualità della ricostruzione dipende da:

• autorizzazioni;
• licenze;
• configurazione;
• retention;
• indicizzazione;
• identificativi;
• endpoint;
• rete;
• tempestività.

Un audit associato a un account non identifica automaticamente una persona.

Un download non coincide sempre con un trasferimento illecito.

Una sincronizzazione non è automaticamente una sottrazione.

Un hold non è un backup.

Un backup non sostituisce gli audit.

L’assenza di un record non dimostra necessariamente che l’azione non sia avvenuta.

La relazione tecnica deve sempre indicare:

- quali fonti sono state interrogate;
- quali query sono state utilizzate;
- quali limiti erano applicabili;
- quali dati sono stati scaricati;
- quali hash sono stati calcolati;
- quali elementi sono osservati;
- quali collegamenti sono dedotti;
- quali ipotesi alternative restano possibili.

133. Anticipazione del capitolo successivo

Capitolo 24 — Autenticità audio: tagli, montaggi e ricodifiche

Il prossimo capitolo tratterà:

• acquisizione del file audio originale;
• formati WAV, MP3, AAC, M4A, OGG e AMR;
• container e codec;
• bitrate;
• sample rate;
• canali;
• durata;
• metadati;
• registrazioni smartphone;
• messaggi vocali WhatsApp e Telegram;
• ricodifiche;
• waveform;
• spettrogramma;
• rumore di fondo;
• discontinuità;
• silenzi;
• tagli;
• montaggi;
• concatenazioni;
• transcodifica;
• clipping;
• analisi con FFmpeg, FFprobe, MediaInfo, Audacity e strumenti specialistici;
• limiti dell’analisi visiva dello spettrogramma;
• confronto tra file;
• sincronizzazione con video e chat;
• trascrizione;
• catena di custodia;
• casi pratici ambientati a Roma;
• formule prudenti per la relazione;
• distinzione tra autenticità tecnica e veridicità delle parole registrate.

Continua con il Capitolo 24 — Autenticità audio: tagli, montaggi e ricodifiche →