Gestire le app di terze parti

Un Google Workspace Administrator governa a chi le app esterne possono accedere. Il canale principale è il Google Workspace Marketplace: puoi permettere l’installazione dell’intero store, consentire solo una allowlist curata di app oppure bloccare tutto, e questa scelta si applica per organizational unit (OU) o per Google Groups, sfruttando l’ereditarietà con override sui sotto-nodi.

Per l’accesso ai dati Google, il punto di controllo sono le API Controls: distingui tra app che usano OAuth (ricevono un token e leggono i dati via API — es. Gmail, Drive) e app configurate con Google come SAML provider, dove Google funge da IdP per il single sign-on verso il servizio terzo ma non concede accesso ai dati. Le password-vaulted app conservano invece username/password condivise per servizi che non supportano SAML/OAuth. Con API access control classifichi ogni app come Trusted, Limited o Blocked in base agli scope richiesti (es. accesso “restricted” a Gmail/Drive richiede verifica).

Il push su mobile avviene tramite la gestione MDM (endpoint management): puoi distribuire app Android/iOS approvate ai dispositivi gestiti. Infine gestisci gli additional services (AdSense, YouTube, e altri servizi non-core): li abiliti o disabiliti per specifiche OU, così ad esempio solo il reparto marketing usa YouTube gestito. La revoca è sempre disponibile: rimuovere l’accesso OAuth di un’app invalida i suoi token immediatamente, per tutti gli utenti dell’ambito interessato.

Autenticazione: 2SV vs SSO/SAML

Il concetto chiave, spesso oggetto di trabocchetti, è la distinzione tra fattore di verifica e federazione dell’identità.

La 2-Step Verification (2SV) è un secondo fattore aggiunto alla credenziale: verifica che l’utente sia chi dice di essere. La applichi via policy per OU/gruppo, con enrollment obbligatorio e periodo di grazia. Per profili ad alto rischio (admin, dirigenti, finance) imponi il metodo più robusto, la security key hardware (FIDO), resistente al phishing; per gli utenti standard puoi accettare metodi come Google Authenticator o i prompt sul telefono, evitando gli SMS quando la sicurezza è prioritaria. Puoi anche usare security key enforcement solo su un gruppo mirato.

Il SSO/SAML riguarda invece chi verifica l’identità. Sono due direzioni opposte:

  • Google come IdP (SP-initiated verso app terze): Google autentica l’utente e rilascia un’asserzione SAML alle app SaaS terze, che così non gestiscono password locali.
  • IdP terzo (Google come SP): un provider esterno (Okta, Entra ID, Ping) autentica gli utenti che poi accedono a Google Workspace. Con il supporto Multi-IdP puoi assegnare IdP diversi a OU/gruppi diversi (es. una controllata su un IdP, il resto su un altro).

Attenzione al rapporto tra i due: quando l’accesso è federato verso un IdP terzo, la 2SV di Google non si applica a quel flusso, perché è l’IdP esterno a gestire l’MFA. La 2SV nativa presidia gli account autenticati direttamente da Google.

Completano il quadro il session control (durata delle sessioni web e reauth periodica per OU) e la già citata API Controls per l’accesso programmatico. Il passing score dell’esame è 700/1000.

Trappole tipiche d’esame

  • Impedire installazione di app non approvate senza bloccare la produttività → allowlist del Marketplace per OU: consenti solo app selezionate invece di aprire o chiudere tutto lo store; la policy segue l’ereditarietà con override.
  • App terza che deve leggere i dati Gmail/Drive vs solo login → OAuth/API Controls vs Google come SAML IdP: SAML SSO federa solo l’autenticazione; per l’accesso ai dati serve controllare gli scope OAuth in API access control.
  • MFA più forte per gli admin, comodo per gli altri → security key per high-risk, Authenticator per gli standard: applica policy 2SV differenziate per OU/gruppo, non un unico metodo globale.
  • Utenti federati verso IdP esterno ma “la 2SV di Google non scatta” → l’MFA lo gestisce l’IdP terzo: con Google come SP la verifica avviene all’IdP; la 2SV nativa vale per account autenticati direttamente da Google.
  • Controllate/reparti con provider di identità diversi → Multi-IdP: assegni IdP distinti a OU/gruppi diversi, non forzi un unico SSO per tutto il dominio.
  • Revocare subito l’accesso di un’app compromessa → revoca OAuth in API Controls, non disinstallo lato utente: rimuovere l’app dalle app connesse invalida i token per l’intero ambito; ricorda che Vault serve a retention/eDiscovery e non ripristina dati né revoca accessi.