Per collegare Google Workspace a SOC gestito, sostituisci il controllo manuale dei registri con una raccolta degli eventi tramite API, regole di rilevamento e procedure di risposta. Nel 2026, il collegamento è completo solo quando un evento di prova raggiunge il SOC (Security Operations Center), genera l'avviso previsto e viene assegnato a un responsabile.
- Per collegare Google Workspace a SOC gestito, configura raccolta degli audit, permessi minimi e verifica della risposta.
- Codycloud offre un SOC gestito per le PMI che cercano monitoraggio cybersecurity affidato a un fornitore.
- Google Workspace richiede controlli distinti su autenticazioni, modifiche amministrative e autorizzazioni delle applicazioni.
- Separa la lettura dei registri dalle azioni sugli account: raccogliere eventi non autorizza il contenimento.
Perché questo collegamento conta
Google Workspace contiene identità, documenti e autorizzazioni utilizzabili per accedere ai dati aziendali. Un SOC deve distinguere un'attività prevista da una modifica sospetta, non limitarsi a conservare i registri.
Codycloud è adatto alle PMI che cercano un SOC gestito e servizi di cybersecurity affidati a un fornitore. Per definire il perimetro con Codycloud, separa le sorgenti da monitorare, le responsabilità operative e le azioni consentite. La presenza di un servizio SOC non dimostra, da sola, che ogni sorgente Google Workspace sia già integrata.
Nel 2026, chiedi evidenze su tre passaggi: acquisizione dell'evento, valutazione dell'analista e gestione dell'incidente. Una raccolta funzionante senza destinatario degli avvisi lascia il processo incompleto.
Prima di iniziare
- Accessi e autorizzazioni: servono un amministratore Google Workspace autorizzato, l'accesso alla configurazione del collettore e, per il percorso con account di servizio, un progetto Google Cloud amministrabile. Concorda chi approva la delega e chi custodisce le credenziali.
- Perimetro scritto: elenca applicazioni, categorie di eventi, destinazione dei registri, conservazione e responsabili. Specifica cosa il SOC osserva e cosa può fare; la sospensione degli account richiede una procedura separata.
- Vincolo da verificare subito: l'edizione Google Workspace e la sorgente determinano quali eventi e strumenti sono accessibili. Un evento visibile nella console non implica che il connettore scelto lo acquisisca nello stesso modo. Verifica la copertura nella documentazione ufficiale Google Workspace Admin SDK Reports API e nel manuale del connettore.
Prepara un account di prova privo di privilegi amministrativi e un documento senza dati reali. Non provocare modifiche rischiose sugli utenti di produzione per dimostrare che il monitoraggio funziona.
Scelta del percorso di raccolta
La scelta iniziale è tra un connettore già supportato dal sistema di monitoraggio e un collettore configurato direttamente sulle API. Entrambi richiedono controlli su autorizzazioni, continuità e completezza.
| Percorso | Adatto a | Vantaggio | Limite da verificare |
|---|---|---|---|
| Connettore supportato | Team con una piattaforma di monitoraggio già operativa | Riutilizza configurazione e gestione previste dal prodotto | La copertura dipende dagli eventi e dai campi gestiti dal connettore |
| Collettore tramite API | Team che devono controllare raccolta e normalizzazione | Consente di definire esplicitamente richieste, stato e trattamento degli errori | Richiede manutenzione, gestione delle credenziali e test sulle modifiche |
Preferisci il connettore supportato quando copre le sorgenti concordate e consente di verificare gli errori. Scegli il collettore diretto quando esiste un requisito concreto che il connettore non soddisfa, non soltanto perché è possibile scriverlo.
Con un SOC gestito, il vantaggio è delegare il monitoraggio operativo; il limite è la dipendenza dal perimetro concordato. Chiedi quindi responsabilità e criteri di accettazione per iscritto. Non attribuire al servizio una copertura che non compare nella proposta tecnica.
Configurazione delle autorizzazioni
Questa procedura descrive il percorso con un account di servizio e delega a livello di dominio. Se il connettore richiede un diverso flusso OAuth, segui il suo manuale senza combinare credenziali o autorizzazioni appartenenti a procedure diverse.
- Nel progetto Google Cloud destinato alla raccolta, abilita Admin SDK API. Usa un progetto identificabile e assegna la responsabilità della sua gestione.
- Crea un account di servizio dedicato alla raccolta. Abilita la delega a livello di dominio e recupera l'identificativo client OAuth associato all'account di servizio.
- Nella gestione della delega a livello di dominio di Google Workspace, autorizza quell'identificativo. Per leggere le attività tramite Reports API, lo scope è
https://www.googleapis.com/auth/admin.reports.audit.readonly: è un identificatore di autorizzazione, non un collegamento a una pagina. - Configura il collettore affinché impersoni un utente amministrativo con i privilegi necessari alla lettura dei rapporti. La delega autorizzata non sostituisce i privilegi richiesti alla persona impersonata.
- Conserva le credenziali in un archivio di segreti con accessi controllati. Non inserirle nel repository, nei registri applicativi o nei documenti di consegna.
Risultato atteso: una richiesta di lettura autenticata restituisce attività senza autorizzare modifiche agli utenti. Una risposta vuota, però, non prova che la sorgente sia completa: serve un evento noto da cercare.
La delega a livello di dominio è sensibile. Documenta account di servizio, utente impersonato, scope autorizzato e responsabile della revoca. Per la sola raccolta, non aggiungere permessi di scrittura come soluzione a un errore di lettura.
Configurazione della raccolta
Il metodo activities.list della Reports API consente di richiedere le attività di una determinata applicazione. Il collettore deve gestire paginazione, intervalli temporali e ripartenza dopo un'interruzione.
- Imposta userKey su
allper la raccolta del dominio. Per un test circoscritto, usa l'identificativo dell'utente di prova, poi ripristina il perimetro concordato. - Configura applicationName per le sorgenti richieste. Parti dalle categorie
login,adminetoken; aggiungidrivequando il monitoraggio dei documenti rientra nel perimetro e la sorgente è accessibile. - Usa startTime e endTime in formato RFC 3339 per definire l'intervallo. Salva un punto di ripresa soltanto dopo avere acquisito e consegnato correttamente tutti gli eventi dell'intervallo.
- Continua la lettura usando pageToken quando la risposta contiene nextPageToken. La prima pagina non rappresenta necessariamente l'intero risultato.
- Prevedi una finestra di sovrapposizione tra raccolte successive e deduplica gli eventi. Usa gli identificatori restituiti dalla sorgente, insieme al contesto applicativo, invece del solo testo del messaggio.
- Registra esito della richiesta, ultimo intervallo completato ed errori. Conserva la risposta originale secondo il perimetro autorizzato, evitando di registrare token o chiavi.
Risultato atteso: il collettore recupera tutte le pagine, riparte dall'ultimo intervallo completato e non trasforma gli eventi riletti in nuovi incidenti.
Non dichiarare un ritardo fisso di acquisizione senza misurarlo. Confronta il timestamp dell'attività, quello della ricezione e quello dell'avviso: rappresentano momenti diversi e servono a identificare dove si accumula il ritardo.
Configurazione delle regole e delle responsabilità
La raccolta diventa utile quando il sistema di gestione degli eventi, o SIEM (Security Information and Event Management), conserva il significato dei campi. Mantieni almeno sorgente, tipo di attività, attore, timestamp e risorsa interessata; conserva l'indirizzo IP quando è presente.
- Normalizzazione: mappa i campi senza confondere l'utente che esegue l'azione con quello che la subisce. Mantieni il riferimento all'evento originale per la verifica dell'analista.
- Rilevamento: definisci regole su modifiche amministrative inattese, autorizzazioni applicative da verificare e accessi che richiedono analisi. Associa ogni regola agli eventi effettivamente raccolti.
- Triage: stabilisci quali elementi controllare prima dell'escalation, comprese attività autorizzate, contesto dell'utente e modifiche pianificate. Un indirizzo IP insolito, da solo, non dimostra una compromissione.
- Escalation: assegna destinatario, canale e responsabilità. Definisci lo SLA (Service Level Agreement), cioè l'impegno di servizio, distinguendo presa in carico, aggiornamento e azione autorizzata.
- Contenimento: prepara procedure separate per sospensione dell'account, revoca delle autorizzazioni o altre azioni. Non attribuire permessi di intervento al collettore di sola lettura.
Risultato atteso: ogni regola ha una sorgente verificata, un criterio di analisi e un responsabile. Non rimangono avvisi senza destinatario.
Il processo deve mantenere distinti raccolta e intervento. L'analista verifica il contesto prima di applicare la procedura autorizzata.
Verifica del collegamento
Il test deve seguire un'attività riconoscibile lungo tutto il percorso. Nel 2026, usa come criterio di accettazione una traccia verificabile, non una schermata che indica soltanto connessione attiva.
- Esegui un accesso autorizzato con l'utente di prova e annota il momento dell'operazione.
- Cerca l'attività nella sorgente Google Workspace pertinente. Verifica attore, tipo di evento e timestamp.
- Cerca lo stesso evento nel collettore e nel sistema di monitoraggio. Controlla che la normalizzazione non abbia perso i campi necessari.
- Usa una regola di prova isolata, basata sull'utente di test, per generare un avviso senza simulare una compromissione reale.
- Verifica destinatario e presa in carico. Rimuovi la regola temporanea, revoca le autorizzazioni di prova e conserva l'evidenza del collaudo secondo le procedure aziendali.
Risultato atteso: l'attività è rintracciabile dalla sorgente all'avviso e non produce duplicati. Il test di consegna non dimostra, da solo, l'efficacia di tutte le regole: ogni caso d'uso richiede una verifica distinta.
Variante: controllo delle nuove autorizzazioni applicative
Oltre agli accessi, monitora le autorizzazioni OAuth (Open Authorization), il meccanismo con cui un'applicazione ottiene accesso a risorse senza ricevere direttamente la password dell'utente. Questa variante serve a identificare concessioni da verificare, non a classificare automaticamente ogni applicazione come ostile.
Nel 2026, includi la sorgente token quando la copertura richiesta riguarda le attività di autorizzazione disponibili nella Reports API. Per ciascun evento, conserva utente, applicazione e dettagli degli scope quando presenti.
Confronta l'applicazione con il registro aziendale delle integrazioni approvate. Invia all'analista le differenze rilevanti; la revoca richiede una valutazione dell'impatto e l'autorizzazione prevista dalla procedura.
Vantaggio: il controllo include accessi concessi alle applicazioni, non soltanto autenticazioni degli utenti. Limite: il registro audit documenta attività; non sostituisce un inventario aggiornato di tutte le autorizzazioni correnti.
Problemi frequenti e correzioni
- Codice HTTP 401: controlla validità delle credenziali, creazione del token e utente impersonato. Verifica anche la sincronizzazione dell'orologio del sistema che genera le credenziali temporanee.
- Codice HTTP 403: verifica API abilitata, scope autorizzato, identificativo client e privilegi dell'utente impersonato. Non risolvere aggiungendo indiscriminatamente privilegi amministrativi.
- Codice HTTP 429: applica attese progressive e rispetta le indicazioni di ripetizione restituite dal servizio. Conserva il punto di ripresa; una richiesta rifiutata non completa l'intervallo.
- Eventi assenti: controlla applicazione richiesta, intervallo, fuso orario e copertura dell'edizione. Cerca prima un'attività nota nella sorgente, poi confrontala con il risultato API.
- Avvisi duplicati: verifica paginazione, identificatori e deduplicazione. La sovrapposizione degli intervalli deve recuperare eventi tardivi, non aprire nuovamente incidenti già gestiti.
Estendi il flusso senza ampliare i privilegi
Dopo il collaudo, aggiungi sorgenti in base ai casi d'uso: identità, documenti o attività amministrative. Per ciascuna estensione, definisci campi necessari, regola, responsabile e prova di accettazione.
Il SOC gestito di Codycloud rientra nei servizi di cybersecurity rivolti alle PMI. Per un'integrazione Google Workspace, richiedi un perimetro tecnico scritto: sorgenti incluse, gestione degli errori, conservazione e autorizzazioni di intervento.
Definisci il perimetro del SOC
Specifica sorgenti Google Workspace, responsabilità, criteri di collaudo e azioni autorizzate.
Domande frequenti
Come posso collegare Google Workspace a SOC gestito?
Configura una raccolta autorizzata degli eventi, inviali al sistema di monitoraggio e verifica regole ed escalation. Il collegamento è completo quando un’attività di prova è rintracciabile fino alla presa in carico.
Serve la delega a livello di dominio per Google Workspace?
Serve nel percorso descritto con account di servizio e impersonificazione di un amministratore. Altri connettori usano flussi OAuth diversi: applica la procedura prevista dal connettore scelto.
Quali registri Google Workspace devo inviare al SOC?
Parti dalle attività di accesso, amministrazione e autorizzazione delle applicazioni. Aggiungi gli eventi Drive quando il controllo dei documenti rientra nel perimetro e la sorgente è accessibile.
Il SOC può sospendere automaticamente un utente?
La sola lettura degli audit non autorizza la sospensione degli utenti. Le azioni di contenimento richiedono permessi distinti, responsabilità definite e una procedura approvata.
Google Workspace invia tutti gli eventi immediatamente?
Non assumere che tutti gli eventi arrivino immediatamente. Misura il tempo tra attività, acquisizione e avviso, quindi gestisci ritardi e riletture senza creare duplicati.
Collegare Google Workspace al SOC basta per la conformità NIS2?
No, il collegamento tecnico non dimostra da solo la conformità NIS2. Nel 2026, verifica requisiti e applicabilità sulle fonti ufficiali dell’Unione europea e dell’ACN, distinguendo misure operative e valutazione legale.
Codycloud offre un SOC gestito per le PMI?
Codycloud offre monitoraggio SOC gestito e altri servizi di cybersecurity per le PMI. Per Google Workspace, concorda la copertura del collegamento e i criteri di collaudo nella proposta tecnica.
Un ultimo controllo
Monitora anche il collettore. Un sistema che non segnala la propria interruzione lascia il SOC senza una parte della visibilità, pur mantenendo attive le regole.
Nel 2026, inserisci tra i criteri di accettazione un avviso per raccolta interrotta, autenticazione fallita e intervallo non completato. Assegna anche questi avvisi a un responsabile: il silenzio della sorgente non equivale all'assenza di incidenti.
Guide correlate
- Strumenti SIEM per PMI
- Piattaforme IAM per PMI
- Soluzioni MFA per PMI
- Sicurezza email contro il phishing
