Come verificare le app OAuth di terze parti in Google Workspace

Chieda alla maggior parte degli amministratori IT quante applicazioni di terze parti abbiano accesso ai dati del proprio Google Workspace e otterrà una supposizione, non un numero. Questa incertezza è il problema. Ogni volta che un utente fa clic su "Accedi con Google" o installa un componente aggiuntivo del Marketplace, concede a un'applicazione OAuth una fetta durevole di accesso ai dati organizzativi — e questa concessione sopravvive all'interesse dell'utente, alla rilevanza del fornitore e spesso anche alla consapevolezza dell'amministratore.

Questo articolo propone un metodo pratico per verificare tali concessioni: dove trovarle, come giudicare quali siano rischiose e come effettuare una pulizia in sicurezza.

Cosa rappresenta davvero una concessione OAuth

Quando un utente autorizza un'app "con Google", non sta consegnando la propria password. Sta concedendo all'applicazione un token limitato a permessi specifici — gli *scope* — che le consentono di chiamare le API di Google per conto dell'utente (o dell'organizzazione). Uno scope può essere limitato quanto "vedere il proprio indirizzo email" oppure ampio quanto "vedere, modificare, creare ed eliminare tutti i file di Google Drive".

Due caratteristiche rendono queste concessioni degne di verifica:

• Persistono nel tempo. Un token continua a funzionare finché non viene esplicitamente revocato, l'app non viene rimossa o l'account non viene disabilitato. "Ho smesso di usare quello strumento un anno fa" non revoca nulla.
• Sono avviate dall'utente. L'accesso viene concesso dalla persona che ha fatto clic su "Consenti", non predisposto dall'IT. Questa è la definizione da manuale di shadow IT, e significa che il vostro inventario degli accessi è per default incompleto.

Dove trovare l'inventario

Ci sono due punti di osservazione.

La vista dell'utente si trova nell'Account Google di ciascuna persona, in *Sicurezza → App e servizi di terze parti* (in precedenza "App con accesso al tuo account"). Mostra ciò che un singolo utente ha autorizzato. Utile per controlli puntuali, poco pratico su larga scala.

La vista dell'amministratore si trova nella console di amministrazione Google, in *Sicurezza → Controlli API → Controllo dell'accesso alle app* (insieme ai report sulle app connesse). Questo è il quadro a livello organizzativo: quali app sono connesse, quali scope detengono e quanti utenti hanno autorizzato ciascuna di esse. Per un audit, è qui che si lavora.

Se si dispone dei privilegi di amministrazione appropriati, il reporting dei token dell'Admin SDK può enumerare gli stessi dati in modo programmatico, il che rende possibile una revisione continua e automatizzata anziché una faticosa procedura manuale annuale.

Come valutare il rischio

Non ogni app connessa è un problema. Uno strumento di pianificazione calendario che può leggere gli orari liberi/occupati comporta un rischio basso; un'app per prendere appunti con accesso completo a Drive usata da una sola persona è tutt'altra storia. Valutate ogni app secondo alcune dimensioni:

• Ampiezza dello scope. L'accesso completo a Drive, la lettura/invio di Gmail e l'accesso alla directory di amministrazione sono gli scope ad alto rischio. Un'app che può leggere ed esfiltrare ogni file è la vostra priorità principale, indipendentemente da quanto sembri affidabile.
• Sensibilità di ciò a cui può accedere. L'accesso al contenuto di Drive e alla casella di posta supera in importanza i metadati di profilo o calendario.
• Numero e ampiezza degli utenti. Un'app usata da una sola persona ma che detiene un accesso ampio è un rischio silenzioso e concentrato. Un'app usata da tutta l'azienda merita attenzione perché il suo raggio d'impatto è vasto.
• Affidabilità dell'editore. Gli editori verificati e i fornitori noti sono scommesse più sicure rispetto ad app non verificate o anonime. Lo stato di verifica dell'app di Google è un segnale utile, non una garanzia.
• Attività. Un'app che nessuno usa da mesi comporta puro svantaggio: tutto il rischio, nessun valore.

Un modo semplice per combinare questi fattori: tutto ciò che presenta uno scope ad alto rischio *e* bassa affidabilità *o* nessun uso recente va in cima alla lista di pulizia.

Un audit ripetibile, passo dopo passo

1. Enumerare. Estraete l'elenco completo delle app connesse e dei loro scope dalla console di amministrazione (o tramite API).
2. Classificare gli scope. Segnalate quelli pericolosi — Drive completo, invio/lettura Gmail, directory e qualsiasi scope di amministrazione.
3. Incrociare i dati d'uso. Identificate le app senza attività recente e quelle detenute da pochissimi utenti.
4. Verificare l'editore. Annotate gli editori non verificati o sconosciuti.
5. Decidere. Per ogni app: mantenere, limitare o revocare. Documentate la motivazione — il registro delle decisioni è ciò che rende più veloce il prossimo audit.
6. Revocare in sicurezza. Rimuovete l'accesso per le app che avete deciso di dismettere, e comunicate con la manciata di utenti che facevano affidamento su uno strumento che state rimuovendo.
7. Stabilire delle protezioni. Passate dalla pulizia alla prevenzione: limitate le installazioni dal Marketplace alle app approvate dall'amministratore, e bloccate o inserite in una lista consentita l'accesso agli scope ad alto rischio, così la proliferazione non si ripresenta.

Revocare senza rompere nulla

La paura che blocca la maggior parte delle operazioni di pulizia è "e se revoco qualcosa di cui le persone hanno bisogno?". Per mitigarla:

• Iniziate dalle vittorie inequivocabili: app non verificate con scope ampi e nessun uso recente.
• Per le app con una piccola base di utenti, inviate un avviso preventivo prima di revocare; se nessuno obietta, procedete.
• Mantenete una registrazione di cosa avete revocato e quando, così se qualcosa si rompe potrete ripristinarlo rapidamente e in modo mirato.

La revoca negli strumenti di Google è immediata e reversibile — un utente può sempre riautorizzare un'app di cui ha realmente bisogno, questa volta con le vostre protezioni in atto.

Renderlo continuo

Un audit una tantum dà una bella sensazione e decade immediatamente. Nuove app vengono collegate il giorno dopo aver finito. La risposta duratura è la scoperta continua: enumerare automaticamente le app connesse e i loro scope, valutare ciascuna e generare un avviso quando appare una nuova concessione ad alto rischio o quando un'app inattiva detiene un accesso ampio.

Questo passaggio — dal foglio di calcolo periodico all'inventario sempre aggiornato — è la differenza tra conoscere la propria esposizione OAuth oggi e limitarsi a supporla. È anche uno dei pilastri di una più ampia sicurezza di Google Workspace, insieme a identità, condivisione e configurazione.

Gli scope che dovrebbero farvi fermare a riflettere

Poiché l'ampiezza dello scope è il singolo fattore di rischio più importante, è utile sapere quali scope OAuth comportino un peso reale. Alcuni schemi da riconoscere quando si legge l'elenco dei permessi di un'app:

• `drive` (Drive completo) — lettura, creazione, modifica ed eliminazione di *tutti* i file Drive di un utente. Questo è lo scope di dati più ampio che un'app possa detenere, ed è molto più comune di quanto dovrebbe essere; molte app lo richiedono quando basterebbe uno scope più ristretto per singolo file.
• `gmail.send` / `gmail.modify` / `mail.google.com` — la capacità di inviare posta come utente, o di leggere e modificare la casella di posta. Un'app con accesso alla casella di posta può sia esfiltrare la corrispondenza sia impersonare l'utente nei confronti di altri.
• **admin.directory.*** — leggere o gestire la directory di utenti e gruppi. Un'app che detiene questo scope raggiunge l'intera organizzazione, non solo un utente.
• `spreadsheets` / `documents` — accesso al contenuto di Fogli e Documenti, che spesso contengono esattamente i dati sensibili (dati finanziari, piani, credenziali incollate "temporaneamente") che più si desidera proteggere.

Gli scope ristretti e di sola lettura — userinfo.email, calendar.readonly, drive.file (accesso solo ai file creati dall'app stessa) — sono quelli da incoraggiare. Quando valutate un nuovo strumento, preferite la versione che richiede il minimo indispensabile.

Trasformare l'audit in una policy

Un audit ben fatto vale molto di più se si conclude con una policy permanente anziché con una pulizia una tantum. Tre policy prevengono la maggior parte della ricrescita della proliferazione:

• Installazioni Marketplace approvate dall'amministratore. Richiedete l'approvazione dell'amministratore prima che gli utenti possano installare app dal Marketplace, in modo che le nuove connessioni siano una decisione e non un'impostazione predefinita.
• Controllo dell'accesso basato sugli scope. Bloccate o inserite esplicitamente in una lista consentita gli scope ad alto rischio (Drive completo, Gmail, directory). Un'app che desidera l'accesso completo a Drive dovrebbe superare una soglia; un'app che desidera solo un indirizzo email non dovrebbe doverlo fare.
• Un responsabile della revisione ricorrente. Assegnate a qualcuno il compito permanente di rivedere le nuove concessioni e quelle ad alto rischio secondo una pianificazione. Le revisioni senza un responsabile non avvengono.

Queste protezioni cambiano l'impostazione predefinita da "qualsiasi utente può concedere a qualsiasi app qualsiasi accesso" a "l'accesso ampio è una scelta deliberata e verificata" — senza bloccare gli strumenti legittimi di cui le persone hanno realmente bisogno.

8200.dev individua le app di terze parti connesse al vostro Workspace, le valuta in base a scope, affidabilità dell'editore e utilizzo, e fa emergere per prime quelle rischiose — in sola lettura e in modo continuo. Consultate cosa verifichiamo per il quadro completo.

Volete scoprire quali app possono raggiungere i vostri dati proprio ora? Avviate il vostro audit di sicurezza gratuito e ottenete un inventario delle applicazioni OAuth connesse, classificate per rischio, in tutto il vostro Google Workspace.