1. Périmètre et architecture d'administration

Cette page complète Google Admin / Workspace (création du tenant, DNS, utilisateurs, OU, réglages de base). Elle s'adresse à l'ingénieur qui doit industrialiser un tenant : automatisation, fédération d'identité, gouvernance des données, conformité, migration et résilience.

1.1 Les plans de contrôle d'un tenant

Plan	Où il se pilote	Ce qu'il porte	Automatisation
Identité	Admin console > Annuaire, Sécurité > Authentification	Utilisateurs, groupes, OU, SSO, 2SV	Admin SDK Directory API, GAM, GCDS, connecteur Entra ID
Politiques	OU et groupes de configuration	Activation des services, partage Drive, règles Gmail	Policy API (lecture), GAM (partiel), Cloud Identity Policy API
Accès	Sécurité > Accès et contrôle des données	Context-Aware Access, contrôles API, délégation domain-wide	Access Context Manager (GCP)
Données	Règles DLP, étiquettes, Vault	Classification, prévention de fuite, rétention légale	Drive Labels API, Vault API
Observabilité	Rapports, Alert Center, Security Center	Journaux d'audit, alertes, tableaux de bord	Reports API, Alert Center API, export BigQuery
Appareils	Appareils	Mobiles, ChromeOS, Windows (GCPW), Endpoint Verification	Directory API (mobile/chromeos), Cloud Identity Devices API

1.2 Héritage OU vs groupes de configuration

Une politique s'applique à une OU (héritage descendant, un utilisateur n'est que dans une OU) ou à un groupe de configuration (un utilisateur peut être dans plusieurs groupes). Règle de préséance : le réglage par groupe l'emporte sur celui de l'OU ; entre deux groupes, c'est l'ordre de priorité défini dans la console qui tranche.

• Utiliser l'OU pour ce qui découle de la structure (licence, site, statut : actifs / sortants / comptes de service).
• Utiliser les groupes pour les exceptions transverses (pilote d'une fonctionnalité, partage externe autorisé pour un projet).
• Prévoir dès le départ une OU /Sortants (services coupés, conservation Vault) et une OU /Service pour les comptes techniques (pas de 2SV interactif, accès restreint).

1.3 Rôles d'administration : moindre privilège

Besoin	Rôle conseillé	À éviter
Support N1 (réinit. mot de passe, déblocage)	Help Desk Admin (prédéfini), limité à certaines OU	User Management Admin global
Gestion des groupes	Groups Admin ou rôle personnalisé Groups	Super admin
Automatisation GAM	Compte dédié avec rôle personnalisé strict	Le compte super admin nominatif d'un humain
Investigations	Rôle avec privilèges Security Center / Investigation Tool	Accès Vault non tracé
eDiscovery juridique	Rôle Vault dédié (gestion des affaires, exports)	Donner Vault au support

Garder 2 à 4 super admins, nominatifs, sans licence de messagerie utilisée au quotidien si possible, protégés par clé de sécurité, plus un compte bris de glace (voir section 8).

2. GAM / GAMADV-XTD3 (GAM7) : installation et projet GCP

GAM est l'outil en ligne de commande de référence pour administrer Google Workspace via les API. Historiquement deux branches coexistaient : GAM (GAM-team, dit « GAM legacy ») et GAMADV-XTD3 (fork très enrichi de Ross Scroggs : multi-tenants, sorties CSV riches, redirect csv, traitements parallèles). Les deux ont été réunies sous le nom GAM7 (dépôt GAM-team), qui reprend la syntaxe de GAMADV-XTD3.

2.1 Installation

# Linux / macOS : script d'installation officiel du projet (vérifier l'URL sur le wiki GAM-team)
bash <(curl -s -S -L https://git.io/gam-install)

# Windows : MSI publié dans les « Releases » GitHub du projet,
# installe par défaut dans C:\GAM7 et ajoute le dossier au PATH.

# Vérifier la version et l'environnement
gam version
gam version checkrc

Placer la configuration hors du dossier binaire (permet les mises à jour sans perte) :

# Linux
export GAMCFGDIR="$HOME/.gam"
mkdir -p "$GAMCFGDIR"

# Windows (PowerShell, persistant pour l'utilisateur)
[Environment]::SetEnvironmentVariable("GAMCFGDIR","D:\GAMConfig","User")

# Initialiser gam.cfg et les dossiers de travail
gam config drive_dir /srv/gam/work save
gam config csv_output_timestamp_column timestamp save

2.2 Projet GCP, client OAuth et compte de service

GAM a besoin de deux identités distinctes :

Fichier	Identité	Usage
client_secrets.json + oauth2.txt	Client OAuth « Desktop » autorisé par un administrateur	Appels Admin SDK au nom de l'admin (annuaire, rapports, rôles)
oauth2service.json	Compte de service avec délégation domain-wide	Agir au nom des utilisateurs (Gmail, Drive, Calendar d'un tiers)

# Crée le projet GCP, active les API nécessaires, crée le client OAuth
# et le compte de service (assistant interactif)
gam create project

# Autorise le client OAuth (choisir les scopes au strict besoin)
gam oauth create

# Afficher les scopes à déléguer, puis vérifier la délégation
gam user admin@example.com check serviceaccount

check serviceaccount liste chaque scope avec PASS/FAIL et fournit l'ID client numérique du compte de service et la chaîne de scopes à coller dans Admin console > Sécurité > Accès et contrôle des données > Commandes des API > Gérer la délégation au niveau du domaine.

2.3 Durcir le projet GCP qui héberge GAM

• Projet GCP dédié, dans un dossier de l'organisation réservé à l'administration, sans autre ressource.
• Rôle IAM Owner limité à 2 personnes ; personne d'autre ne doit pouvoir créer de clé pour le compte de service (iam.serviceAccountKeyAdmin).
• Les organisations récentes appliquent par défaut la contrainte iam.disableServiceAccountKeyCreation. La lever uniquement sur ce projet (exception de politique au niveau projet), pas sur l'organisation.
• Rotation des clés du compte de service : gam rotate sakey (GAM7) puis supprimer l'ancienne clé ; vérifier dans IAM > Comptes de service > Clés qu'il ne reste qu'une clé active.
• Journaliser : les journaux d'audit Cloud (Admin Activity) tracent la création de clés ; créer une alerte sur google.iam.admin.v1.CreateServiceAccountKey.

2.4 Multi-tenants (prestataire, filiales)

# Une section par tenant dans gam.cfg, chacune avec son propre config_dir
gam config section clientA config_dir /srv/gam/clientA save
gam config section clientB config_dir /srv/gam/clientB save

# Exécuter une commande sur un tenant précis
gam select clientA print users count
gam select clientB save   # définit la section par défaut

3. GAM : commandes d'audit et opérations de masse

3.1 Audit des comptes

# Inventaire complet des comptes avec 2SV, dernière connexion, OU, statut
gam redirect csv ./users.csv print users fields primaryemail,name,orgunitpath,suspended,isadmin,isdelegatedadmin,isenrolledin2sv,isenforcedin2sv,lastlogintime,creationtime

# Comptes actifs sans 2SV
gam print users query "isEnrolledIn2Sv=false isSuspended=false" fields primaryemail,orgunitpath

# Comptes inactifs depuis plus de 90 jours (filtrer ensuite le CSV sur lastlogintime)
gam print users query "isSuspended=false" fields primaryemail,lastlogintime

# Liste des super admins et administrateurs délégués
gam print users query "isAdmin=true" fields primaryemail,lastlogintime,isenrolledin2sv
gam print admins

# Affectations de rôles et privilèges des rôles personnalisés
gam print adminroles privileges

3.2 Audit des accès tiers (OAuth) et des délégations

# Jetons OAuth accordés par tous les utilisateurs (applications tierces)
gam redirect csv ./tokens.csv multiprocess all users print tokens

# Révoquer une application donnée pour tout le monde
gam all users delete token clientid 123456789012-abcdefexample.apps.googleusercontent.com

# Délégations de boîte (Gmail delegates) et transferts automatiques
gam redirect csv ./delegates.csv multiprocess all users print delegates
gam redirect csv ./forwards.csv multiprocess all users print forwards
gam redirect csv ./fwdaddr.csv multiprocess all users print forwardingaddresses

3.3 Audit du partage Drive

# Fichiers partagés « tout le monde avec le lien » ou publics, pour tous les utilisateurs
gam config auto_batch_min 1 redirect csv ./public.csv multiprocess all users print filelist query "visibility='anyoneWithLink' or visibility='anyoneCanFind'" fields id,name,owners.emailaddress,webviewlink,modifiedtime

# Fichiers partagés avec des domaines externes (permissions détaillées)
gam redirect csv ./perms.csv multiprocess all users print filelist fields id,name,permissions pm type user em not domain example.com

# Drives partagés : inventaire, organisateurs, membres externes
gam redirect csv ./shareddrives.csv print shareddrives fields id,name,createdtime,restrictions
gam redirect csv ./sdacl.csv print shareddriveacls

3.4 Opérations de masse depuis un CSV

# Création en masse (colonnes : email,first,last,ou)
# Le mot de passe initial est aléatoire et le changement forcé à la 1re connexion
gam csv ./arrivees.csv gam create user ~email firstname ~first lastname ~last org ~ou password random changepassword on

# Déplacement d'OU en masse
gam csv ./move.csv gam update user ~email ou ~ou

# Ajout aux groupes
gam csv ./membres.csv gam update group ~group add member user ~email

# Mise à jour d'attributs personnalisés (schéma « RH » déclaré au préalable)
gam csv ./rh.csv gam update user ~email RH.Matricule ~matricule RH.Site ~site

3.5 Procédure de départ (offboarding) scriptable

#!/usr/bin/env bash
# offboard.sh <utilisateur> <responsable>
set -euo pipefail
U="$1"; M="$2"

gam user "$U" signout                                   # ferme toutes les sessions web
gam user "$U" deprovision                               # révoque jetons OAuth, mots de passe d'application, codes de secours
gam update user "$U" password random                    # mot de passe aléatoire
gam user "$U" delete forwardingaddresses                # supprime les transferts
gam user "$U" delete delegates                          # supprime les délégations de boîte
gam user "$U" vacation on subject "Absent" message "Merci d'écrire à $M"
gam update user "$U" ou /Sortants                       # OU sans services, conservée par Vault
gam create datatransfer "$U" gdrive "$M" privacy_level shared,private
gam create datatransfer "$U" calendar "$M" release_resources true
gam update user "$U" suspended on                       # suspension finale
echo "Offboarding $U terminé - transfert vers $M lancé"

3.6 Rapports (Reports API) en CLI

# Activité d'administration des 7 derniers jours
gam report admin start -7d

# Connexions suspectes ou refusées
gam report login filter "is_suspicious==true" start -30d
gam report login event login_failure start -1d

# Indicateurs par utilisateur (stockage, 2SV, dernière connexion)
gam report users parameters accounts:is_2sv_enrolled,accounts:last_login_time,accounts:used_quota_in_mb

3.7 Industrialiser : audit mensuel planifié

Les commandes ci-dessus prennent leur valeur quand elles tournent seules, produisent un historique et alertent sur les écarts. Exemple sur un serveur d'administration Linux dédié :

#!/usr/bin/env bash
# /opt/gw-audit/audit.sh - audit mensuel du tenant, sorties horodatées
set -euo pipefail
export GAMCFGDIR=/srv/gam/config
OUT=/srv/gw-audit/$(date +%F)
mkdir -p "$OUT"
GAM=/opt/gam7/gam

$GAM redirect csv "$OUT/users.csv"   print users fields primaryemail,orgunitpath,suspended,isadmin,isenrolledin2sv,lastlogintime
$GAM redirect csv "$OUT/admins.csv"  print admins
$GAM redirect csv "$OUT/tokens.csv"  multiprocess all users print tokens
$GAM redirect csv "$OUT/forwards.csv" multiprocess all users print forwards
$GAM redirect csv "$OUT/delegates.csv" multiprocess all users print delegates

# Indicateurs simples : comptes actifs sans 2SV
NO2SV=$(awk -F, 'NR>1 && $3=="False" && $5=="False"' "$OUT/users.csv" | wc -l)
echo "Comptes actifs sans 2SV : $NO2SV" | tee "$OUT/resume.txt"

# Différentiel des super admins par rapport au mois précédent
PREV=$(ls -1d /srv/gw-audit/*/ | sort | tail -n 2 | head -n 1)
diff <(sort "$PREV/admins.csv") <(sort "$OUT/admins.csv") > "$OUT/admins.diff" || true

# Les CSV contiennent des données personnelles : droits restreints
chmod -R go-rwx "$OUT"

# /etc/systemd/system/gw-audit.service
[Unit]
Description=Audit mensuel Google Workspace (GAM)
After=network-online.target

[Service]
Type=oneshot
User=gamsvc
ExecStart=/opt/gw-audit/audit.sh

# /etc/systemd/system/gw-audit.timer
[Unit]
Description=Planification audit Google Workspace

[Timer]
OnCalendar=*-*-01 06:00:00
Persistent=true

[Install]
WantedBy=timers.target

4. Admin SDK, comptes de service et scopes

4.1 Deux modèles d'authentification

Modèle	Principe	Avantages	Limites
OAuth utilisateur (admin)	Un admin consent, on stocke un refresh token	Droits = rôle de l'admin (moindre privilège possible)	Refresh token lié à une personne ; révoqué si mot de passe changé selon scopes
Compte de service + délégation domain-wide	Le SA « impersonne » un utilisateur (claim sub)	Pas d'interaction, peut agir au nom de n'importe quel utilisateur	Très puissant ; limiter les scopes à l'octet près
Compte de service + rôle admin	Le SA reçoit lui-même un rôle d'administration Workspace	Pas besoin d'impersonner un admin humain	Couvre l'Admin SDK, pas les données utilisateur (Gmail, Drive)

4.2 Scopes : choisir au plus juste

Besoin	Scope
Lire l'annuaire	https://www.googleapis.com/auth/admin.directory.user.readonly
Gérer les groupes	https://www.googleapis.com/auth/admin.directory.group
Lire les journaux d'audit	https://www.googleapis.com/auth/admin.reports.audit.readonly
Lire les réglages Gmail (transferts, délégations)	https://www.googleapis.com/auth/gmail.settings.basic (lecture/écriture des réglages, pas des messages)
Métadonnées Drive uniquement	https://www.googleapis.com/auth/drive.metadata.readonly
Vault	https://www.googleapis.com/auth/ediscovery (ou .readonly)
Alert Center	https://www.googleapis.com/auth/apps.alerts

Règle : un compte de service par usage (export des journaux, synchronisation RH, sauvegarde), chacun avec sa liste de scopes. Un outil de reporting n'a jamais besoin de https://mail.google.com/.

4.3 Exemple Python : lecture de l'annuaire par impersonation

# pip install google-api-python-client google-auth
from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = ["https://www.googleapis.com/auth/admin.directory.user.readonly"]
creds = service_account.Credentials.from_service_account_file(
    "/etc/gw-sync/sa.json", scopes=SCOPES
).with_subject("svc-annuaire@example.com")   # admin impersonné (rôle restreint)

svc = build("admin", "directory_v1", credentials=creds, cache_discovery=False)
req = svc.users().list(customer="my_customer", maxResults=500,
                       query="isSuspended=false", orderBy="email")
while req is not None:
    resp = req.execute()
    for u in resp.get("users", []):
        print(u["primaryEmail"], u.get("isEnrolledIn2Sv"), u.get("lastLoginTime"))
    req = svc.users().list_next(req, resp)

4.4 Se passer des clés JSON

Une clé JSON de compte de service est un secret longue durée. Alternatives à privilégier quand le code tourne :

• Sur GCP (Cloud Run, GCE, Cloud Functions) : identité attachée + API iamcredentials.signJwt pour signer le JWT de délégation sans clé locale.
• Hors GCP (Azure, AWS, GitLab CI, GitHub Actions) : Workload Identity Federation, qui échange un jeton OIDC de la plateforme contre un jeton Google ; combiné à signJwt, la délégation domain-wide fonctionne sans aucune clé stockée.

4.5 Quotas et robustesse

• Les API renvoient 403 rateLimitExceeded, 403 userRateLimitExceeded ou 429 : implémenter un backoff exponentiel avec aléa, pas un simple sleep 1.
• Utiliser les requêtes par lots (batch) et le paramètre fields pour réduire la charge.
• Les quotas par projet sont visibles dans la console GCP (API et services > Quotas) ; certains se négocient.
• Les changements faits via l'API mettent de quelques secondes à plusieurs heures à se propager (groupes, politiques) : ne pas enchaîner « créer puis vérifier immédiatement » sans tolérance.

5. SSO SAML : Google comme fournisseur de services

5.1 Principe

Avec un IdP tiers (Entra ID, Okta, Keycloak, ADFS...), Google devient SP : l'utilisateur saisit son adresse sur accounts.google.com, est redirigé vers l'IdP, puis revient avec une assertion SAML. Google ne connaît plus le mot de passe ; la MFA est portée par l'IdP. Google prend en charge plusieurs profils SSO tiers, assignés par OU ou par groupe, ce qui permet une bascule progressive.

5.2 Paramètres côté Google (profil SSO)

Paramètre	Valeur
URL de connexion	URL SAML de l'IdP (ex. https://login.microsoftonline.com/<tenant-id>/saml2)
URL de déconnexion	URL de déconnexion de l'IdP (facultatif mais conseillé)
Certificat de vérification	Certificat de signature de l'IdP (PEM). Noter sa date d'expiration.
URL de changement de mot de passe	Portail de l'IdP (SSPR)
Entity ID (SP)	Fourni par Google pour le profil (format https://accounts.google.com/samlrp/... pour les profils récents ; google.com/a/example.com pour le profil hérité)
ACS URL	Fournie par Google pour le profil
NameID	Adresse principale Google (user.userprincipalname si UPN = e-mail, sinon user.mail)

5.3 Côté Entra ID

1. Applications d'entreprise > Nouvelle application > galerie : application Google Cloud / Google Workspace.
2. Authentification unique > SAML : renseigner l'Identifier (Entity ID) et la Reply URL (ACS) exactement comme dans le profil Google.
3. Revendication d'identifiant unique : choisir l'attribut dont la valeur égale l'adresse Google principale.
4. Télécharger le certificat (Base64), l'importer dans le profil Google.
5. Affecter les utilisateurs/groupes à l'application et appliquer une stratégie d'accès conditionnel (MFA résistante au phishing, appareil conforme). Voir Entra ID.
6. Dans Google : Sécurité > Authentification > SSO avec un IdP tiers, affecter le profil à une OU pilote.

5.4 Points de conception

• Network masks : un profil peut ne s'appliquer qu'aux connexions depuis certaines plages ; à utiliser avec prudence (télétravail).
• Challenge Google après SSO : on peut demander à Google de ne pas imposer sa propre 2SV après une assertion valide (MFA portée par l'IdP) ; vérifier le réglage « Ignorer les validations supplémentaires » en fonction de la confiance accordée à l'IdP.
• Certificat IdP : son expiration coupe toute connexion. Prévoir une alerte à J-60 et la procédure de rotation (importer le nouveau certificat côté Google avant de l'activer côté IdP).
• Applications natives : les clients Google (Drive pour ordinateur, apps mobiles) suivent le flux navigateur ; les clients IMAP n'en bénéficient pas (voir section 16 : désactiver l'accès « moins sécurisé »).

5.5 Google comme IdP (cas inverse)

Google peut aussi être IdP SAML pour des applications tierces (Applications > Applications Web et mobiles > Ajouter une application SAML personnalisée). Dans ce cas, le contrôle d'accès passe par l'activation de l'application par OU/groupe, et le Context-Aware Access peut s'appliquer à ces applications SAML (selon édition).

6. Provisioning : Entra ID et GCDS depuis AD

6.1 Choisir la source d'autorité

Source	Outil	Sens	Mots de passe	Cas typique
Active Directory on-prem	Google Cloud Directory Sync (GCDS)	AD -> Google (unidirectionnel)	Non (sauf outil Password Sync sur les DC) ou SSO	SI historique Windows, pas d'Entra ID
Entra ID	Provisioning automatique de l'application d'entreprise	Entra -> Google	Non, SSO SAML obligatoire en pratique	Tenant M365 + Google Workspace en parallèle
SIRH	Connecteur SIRH / script API	SIRH -> IdP -> Google	Via IdP	Cycle arrivée/départ piloté par les RH
Google (maître)	Console / GAM	-	Google	Petite structure 100 % cloud

Ne jamais avoir deux moteurs qui écrivent les mêmes objets (GCDS et provisioning Entra en même temps) : ils se défont mutuellement leurs changements.

6.2 GCDS : architecture

• Application Java installée sur un serveur membre (pas sur un DC si possible), connectée en LDAPS (636) à AD avec un compte de lecture dédié.
• Configuration dans un fichier XML (Configuration Manager), exécution planifiée via sync-cmd.
• Règles de recherche LDAP par type d'objet : utilisateurs, groupes, OU, contacts partagés, ressources de calendrier.
• Règles d'exclusion côté Google : indispensables pour ne pas supprimer les comptes créés uniquement dans Google (super admins, comptes de service, bris de glace).

6.3 GCDS : filtres LDAP utiles

# Utilisateurs actifs d'une OU, avec e-mail renseigné
(&(objectCategory=person)(objectClass=user)(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

# Membres d'un groupe AD « GW-Licence » (y compris imbriqués)
(&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=GW-Licence,OU=Groupes,DC=corp,DC=example,DC=com))

# Groupes de messagerie à synchroniser
(&(objectClass=group)(mail=*)(extensionAttribute1=google))

6.4 GCDS : exécution et planification

REM Simulation (aucune modification), journal détaillé
"C:\Program Files\Google Cloud Directory Sync\sync-cmd.exe" -c "D:\GCDS\prod.xml" -l "D:\GCDS\logs\sim.log"

REM Application réelle (-a) ; -r génère un rapport
"C:\Program Files\Google Cloud Directory Sync\sync-cmd.exe" -a -c "D:\GCDS\prod.xml" -r "D:\GCDS\logs\report.html"

Planifier via le Planificateur de tâches, sous un compte de service gMSA ou un compte local dédié, toutes les 1 à 4 heures. Configurer dans l'XML les seuils de suppression (limite de suppressions par exécution) : c'est le garde-fou contre une erreur de filtre LDAP qui supprimerait tout le tenant.

6.5 Provisioning depuis Entra ID

1. Dans l'application d'entreprise Google : Provisionnement > Automatique, autoriser avec un compte admin Google dédié.
2. Définir l'étendue : « utilisateurs et groupes affectés » uniquement.
3. Mappage d'attributs : userPrincipalName ou mail vers primaryEmail, département, manager, OU (expression de mappage).
4. Tester avec Provisionner à la demande sur un utilisateur pilote, lire le journal de provisionnement.
5. Activer, surveiller la mise en quarantaine (taux d'erreur élevé) dans les journaux Entra.

Le cycle par défaut est d'environ 40 minutes ; la désaffectation d'un utilisateur le suspend côté Google (comportement à vérifier dans la doc Microsoft de l'application, il peut évoluer).

7. Context-Aware Access

7.1 Architecture

Context-Aware Access (CAA) conditionne l'accès aux applications Workspace selon le contexte : IP, pays, état de l'appareil (chiffrement, verrouillage écran, OS à jour, appareil d'entreprise). Il repose sur des niveaux d'accès définis dans Access Context Manager (GCP) et sur les signaux d'Endpoint Verification (extension Chrome + aide native) ou de la gestion des appareils.

7.2 Exemples de niveaux d'accès (CEL)

// Appareil d'entreprise, chiffré, verrouillé par mot de passe
device.is_corp_owned_device == true &&
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock == true

// Pays autorisés
origin.region_code in ["FR", "BE", "CH"]

// Version minimale de l'OS Windows (adapter au parc)
device.os_type == OsType.DESKTOP_WINDOWS &&
device.os_version.compareVersions("10.0.19045") >= 0

7.3 Déploiement sans casse

1. Déployer Endpoint Verification sur le parc (extension Chrome forcée par politique) et vérifier la remontée des appareils.
2. Créer les niveaux d'accès, les affecter en mode surveillance (Monitor mode) à une OU pilote.
3. Analyser dans le journal d'audit « Context-Aware Access » les accès qui auraient été refusés.
4. Passer en mode actif, OU par OU, avec un message de refus personnalisé renvoyant vers le support.
5. Exclure les comptes bris de glace et les comptes de service (qui n'ont pas d'appareil).

7.4 Matrice de conception type

Population	Applications	Niveau d'accès exigé	Comportement hors niveau
Administrateurs	Admin console, Vault, GCP	Appareil d'entreprise chiffré + pays autorisé	Refus
Finance / RH	Drive, Gmail	Appareil d'entreprise ou BYOD avec profil professionnel	Refus
Utilisateurs standards	Drive	Appareil chiffré avec verrouillage	Accès web uniquement (selon fonctionnalités disponibles) ou refus
Prestataires	Drive partagé projet	Pays autorisés	Refus
Comptes de service, bris de glace	-	Exclus	-

8. Protection avancée, clés de sécurité, comptes super admin

8.1 Hiérarchie des méthodes 2SV

Méthode	Résistance au phishing	Recommandation
Clé de sécurité FIDO2 / passkey	Oui (liée à l'origine)	Obligatoire pour admins, finance, direction
Invite Google sur téléphone	Partielle (fatigue MFA, proxy AitM)	Acceptable pour les utilisateurs standards
Application TOTP	Non (code relayable)	Transition seulement
SMS / appel	Non (SIM swap)	À interdire
Codes de secours	Non	Coffre-fort uniquement (bris de glace)

Dans Sécurité > Validation en deux étapes, par OU : Application obligatoire, période d'inscription courte, et méthodes autorisées = « Clé de sécurité uniquement » pour l'OU des administrateurs.

8.2 Advanced Protection Program (APP)

APP impose clés/passkeys, bloque la plupart des applications tierces non vérifiées, renforce l'analyse des pièces jointes et durcit la récupération de compte. L'inscription se fait par l'utilisateur après autorisation de l'admin (Sécurité > Protection avancée). Cibles : super admins, dirigeants, comptes à forte exposition.

8.3 Comptes de bris de glace

• Deux comptes super admin non nominatifs, sans boîte utilisée, dans une OU dédiée exclue de CAA et du SSO.
• Deux clés FIDO2 chacun, conservées dans deux coffres physiques distincts ; codes de secours imprimés et scellés.
• Alerte (règle d'activité) sur toute connexion de ces comptes.
• Test de connexion trimestriel tracé.

8.4 Autres réglages de durcissement

• Contrôles des API : passer l'accès des applications tierces en « Restreint » et n'autoriser que les applications approuvées (Applications de confiance) ; bloquer les apps non configurées pour les mineurs/l'OU sensible.
• Durée de session web : 12 h à 24 h pour les utilisateurs, plus court pour les admins.
• Récupération de compte en libre-service : désactivée pour les super admins.
• Mots de passe d'application : désactivés sauf exception documentée.
• Connexion « Se connecter avec Google » sur des services tiers : auditer via le journal OAuth.

8.5 Sécurité Gmail avancée

Réglage	Emplacement	Recommandation
Sécurité avancée anti-hameçonnage et logiciels malveillants	Gmail > Sécurité	Tout activer ; action « mettre en quarantaine » pour les pièces jointes de types inhabituels et l'usurpation de domaine/employé
Sandbox de sécurité (pièces jointes)	Gmail > Sécurité	Activer (selon édition), au minimum pour les OU exposées
Analyse des liens et images externes	Gmail > Sécurité	Activer la réécriture/analyse des liens
Avertissement destinataire externe	Gmail > Paramètres utilisateur	Activer (bannière sur les réponses à l'externe)
Quarantaines administrateur	Gmail > Gestionnaire de quarantaine	Une quarantaine par type de règle, avec notification d'un groupe SOC
Exigence TLS	Gmail > Conformité	TLS obligatoire vers les partenaires sensibles (banque, expert-comptable) ; MTA-STS publié pour le domaine
Chiffrement côté client (CSE)	Sécurité > Contrôle d'accès et des données	Pour les données les plus sensibles : clés détenues par un service externe ; impose des limites fonctionnelles, à évaluer

# MTA-STS : enregistrement DNS + politique servie en HTTPS
_mta-sts.example.com.  IN TXT "v=STSv1; id=20261019"
# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

# Rapports TLS-RPT
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Passer mode: enforce après quelques semaines de rapports TLS-RPT sans anomalie. Vérifier la liste exacte des MX proposés par Google pour le tenant (certains tenants récents utilisent un MX unique smtp.google.com).

9. DLP et étiquettes Drive

9.1 Modèle

Une règle DLP combine : périmètre (OU/groupes), déclencheur (partage Drive, envoi Gmail, message Chat, impression/téléchargement selon édition), conditions (détecteurs prédéfinis : IBAN, numéro de sécurité sociale français, carte bancaire ; expressions régulières ; listes de mots ; étiquettes) et actions (bloquer, avertir, auditer seulement, appliquer une étiquette).

9.2 Étiquettes Drive (Drive labels)

Type	Usage	Exemple
Étiquette à badge	Classification visible, une valeur par fichier	Public / Interne / Confidentiel / Secret
Étiquette standard	Métadonnées structurées (champs)	Projet, client, durée de conservation

Les étiquettes sont exploitables par la DLP (« si étiquette = Confidentiel, bloquer le partage externe »), par Vault (règles de rétention par étiquette) et par la recherche. Elles peuvent être appliquées automatiquement par une règle DLP qui détecte un contenu.

9.3 Exemple de politique progressive

1. Mois 1 : règles en audit seul (aucune action), mesurer les volumes dans le journal « Règles ».
2. Mois 2 : avertissement utilisateur sur le partage externe de fichiers contenant des IBAN.
3. Mois 3 : blocage du partage externe pour « Confidentiel », étiquetage automatique des fichiers contenant des données de santé.

# Exemple d'expression régulière de détecteur personnalisé (référence de contrat interne)
\bCTR-[0-9]{4}-[0-9]{6}\b

# Mesurer l'effet : journal des règles (DLP) via GAM
gam report rules start -7d

9.4 Partage externe : réglages structurants

• Liste blanche de domaines de confiance pour le partage externe, par OU.
• Interdire la création de liens « Tout le monde » dans les OU sensibles.
• Drives partagés : empêcher les membres de modifier les paramètres et d'ajouter des externes ; préférer les Drives partagés aux « Mon Drive » pour les données d'équipe (le fichier appartient à l'organisation, pas à l'employé).

10. Google Vault : rétention, holds, exports

10.1 Les trois mécanismes

Mécanisme	Effet	Priorité
Règle de rétention par défaut	Conserve (et éventuellement purge après N jours) toutes les données d'un service pour toute l'organisation	La plus faible
Règle de rétention personnalisée	Cible une OU, un Drive partagé, des termes, des étiquettes	Prime sur la règle par défaut
Conservation légale (hold)	Conserve indéfiniment les données de comptes/OU ciblés dans le cadre d'une affaire	Prime sur toute règle de purge

Quand une règle a une action « purger après la période », les données sont définitivement supprimées une fois la période écoulée et la corbeille vidée, y compris de la boîte de l'utilisateur. Une erreur de configuration se paie donc en perte de données : faire valider toute règle de purge par le juridique/DPO.

10.2 Affaires (matters), recherches et exports

1. Créer une affaire, y ajouter les collaborateurs (accès tracé).
2. Poser les holds sur les comptes concernés (Gmail, Drive, Chat, Groups, Meet, Voice selon les besoins).
3. Rechercher (opérateurs Gmail/Drive), prévisualiser, enregistrer la requête.
4. Exporter : MBOX ou PST pour la messagerie, formats natifs ou convertis pour Drive, avec fichiers de métadonnées et sommes de contrôle.
5. Télécharger dans le délai de disponibilité de l'export (limité dans le temps, vérifier la durée actuelle), vérifier les hachages.

# Vault via GAM (syntaxe GAM7)
gam create vaultmatter name "AFF-2026-014 Litige fournisseur" description "Demande juridique du 12/10"
gam create vaulthold matter "AFF-2026-014 Litige fournisseur" name "Hold mail" corpus mail accounts alice@example.com,bob@example.com
gam create vaultexport matter "AFF-2026-014 Litige fournisseur" name "Export mail" corpus mail accounts alice@example.com terms "from:fournisseur.example.org" format pst
gam print vaultexports matter "AFF-2026-014 Litige fournisseur"
gam download vaultexport "AFF-2026-014 Litige fournisseur" "Export mail" targetfolder /srv/vault-exports

10.3 Gouvernance de Vault

• Vault a son propre journal d'audit : il trace qui a cherché quoi. Le revoir mensuellement.
• Un administrateur Vault peut lire tout le contenu de l'organisation : rôle réservé à 1-2 personnes, avec 2SV par clé.
• Les exports contiennent des données personnelles : stockage chiffré, durée de conservation définie, destruction tracée.

11. Journaux d'audit, Alert Center et export BigQuery

11.1 Sources de journaux

Journal	Contenu	Usage sécurité
Admin	Toute action dans la console ou via API admin	Escalade de privilèges, changement de politique
Login	Connexions, échecs, connexion suspecte, changement 2SV	Bourrage d'identifiants, prise de contrôle
Drive	Création, partage, téléchargement, changement de visibilité	Exfiltration
Gmail	Livraison, règles, actions utilisateur	Hameçonnage, règles malveillantes
OAuth Token	Autorisations d'applications tierces	Consent phishing
SAML	Connexions SSO vers les apps SAML	Suivi des accès applicatifs
Règles	Déclenchements DLP et règles d'activité	Efficacité de la DLP

La rétention native de la plupart des journaux est de l'ordre de 6 mois (certains moins) : pour un besoin de 1 an ou plus (NIS2, ISO 27001, enquête), il faut exporter.

11.2 Alert Center et règles d'activité

• Activer les notifications e-mail sur les alertes critiques : connexion suspecte, attaque soutenue par un État, compte d'admin modifié, appareil compromis, exfiltration Drive, règle de transfert vers l'externe.
• Créer des règles d'activité (selon édition) : « attribution du rôle super admin », « connexion d'un compte bris de glace », « plus de 500 téléchargements Drive en 1 h par un utilisateur ».
• Pousser les alertes vers le SIEM via l'Alert Center API ou les connecteurs natifs de Google SecOps / Microsoft Sentinel / autre SIEM.

11.3 Export BigQuery

Rapports > Export BigQuery : désigner un projet GCP et un dataset ; Google y écrit en continu deux tables, activity (événements d'audit) et usage (statistiques quotidiennes). Points d'attention :

• Le compte qui active l'export doit avoir les droits sur le projet ; un compte de service Google est ajouté au dataset.
• Les données ne sont pas rétroactives au-delà de ce que Google remplit à l'activation.
• Définir l'expiration des partitions du dataset selon la politique de rétention (coût de stockage).
• Le schéma peut évoluer : consulter le schéma réel de la table avant d'écrire des requêtes en production.

-- Fichiers rendus publics ces 7 derniers jours (adapter les noms de champs au schéma réel)
SELECT
  TIMESTAMP_MICROS(time_usec) AS quand,
  email                       AS acteur,
  drive.doc_title             AS fichier,
  drive.visibility            AS visibilite
FROM `projet-audit.workspace_logs.activity`
WHERE record_type = 'drive'
  AND event_name  = 'change_document_visibility'
  AND drive.visibility IN ('people_with_link', 'public_on_the_web')
  AND time_usec > UNIX_MICROS(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY))
ORDER BY quand DESC;

-- Top 20 des téléchargements Drive par utilisateur sur 24 h
SELECT email, COUNT(*) AS nb
FROM `projet-audit.workspace_logs.activity`
WHERE record_type = 'drive' AND event_name = 'download'
  AND time_usec > UNIX_MICROS(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY))
GROUP BY email ORDER BY nb DESC LIMIT 20;

Pour les éditions sans export BigQuery, collecter via la Reports API (script planifié, GAM report, ou connecteur du SIEM) en conservant le dernier horodatage traité pour ne rien perdre.

11.4 Collecteur Reports API minimal (JSON lines vers le SIEM)

# pip install google-api-python-client google-auth
import json, pathlib, datetime
from google.oauth2 import service_account
from googleapiclient.discovery import build

STATE = pathlib.Path("/var/lib/gw-logs/state.json")
OUT   = pathlib.Path("/var/log/gw-logs")
APPS  = ["admin", "login", "drive", "token", "saml", "rules"]

creds = service_account.Credentials.from_service_account_file(
    "/etc/gw-logs/sa.json",
    scopes=["https://www.googleapis.com/auth/admin.reports.audit.readonly"],
).with_subject("svc-logs@example.com")
svc = build("admin", "reports_v1", credentials=creds, cache_discovery=False)

state = json.loads(STATE.read_text()) if STATE.exists() else {}
now = datetime.datetime.now(datetime.timezone.utc)
for app in APPS:
    # Rejouer une marge de 30 min : certains événements arrivent en retard
    start = state.get(app) or (now - datetime.timedelta(days=1)).isoformat()
    req = svc.activities().list(userKey="all", applicationName=app,
                                startTime=start, maxResults=1000)
    with open(OUT / f"{app}-{now:%Y%m%d}.jsonl", "a", encoding="utf-8") as f:
        while req is not None:
            resp = req.execute()
            for item in resp.get("items", []):
                f.write(json.dumps(item, ensure_ascii=False) + "\n")
            req = svc.activities().list_next(req, resp)
    state[app] = (now - datetime.timedelta(minutes=30)).isoformat()
STATE.write_text(json.dumps(state))

La marge de recouvrement crée des doublons : dédupliquer côté SIEM sur l'identifiant id.uniqueQualifier + id.time. Le délai de disponibilité des événements varie selon l'application (de quelques minutes à plusieurs heures) : ne pas conclure à une absence d'activité sur la dernière heure.

12. Migrations (vers et depuis Google Workspace)

12.1 Outils Google

Outil	Sources	Volumétrie	Remarques
Service de migration de données (Admin console)	IMAP, Exchange Online/on-prem (EWS), autre compte Google ; Drive depuis certaines sources selon version	Petite à moyenne	Sans infrastructure ; réexécutable en delta
Google Workspace Migrate	Exchange, SharePoint/OneDrive, Box, file shares, autre tenant Google	Grande (milliers d'utilisateurs, To)	Serveurs Windows on-prem/cloud (plateforme + nœuds), soumis à conditions d'éligibilité
GWMME (migration pour Exchange)	Exchange, PST	Moyenne	Outil historique, vérifier son statut de support
Outils tiers (BitTitan, AvePoint, etc.)	Toutes	Toutes	Payants, utiles pour les migrations tenant-à-tenant complexes

12.2 Plan type M365 -> Google Workspace

1. Inventaire : boîtes (taille, nombre d'éléments), boîtes partagées, groupes, sites SharePoint, OneDrive, règles de transport, applications SMTP.
2. Mapping : boîte partagée -> Groupe collaboratif ou boîte déléguée ; site SharePoint -> Drive partagé ; liste de distribution -> Google Group.
3. Provisioning des comptes Google (section 6), sans changer le MX.
4. Pré-migration des données anciennes (J-30 à J-7).
5. Bascule : baisser le TTL du MX à J-2, changer MX/SPF/DKIM le jour J, delta final.
6. Coexistence courte : routage double ou partagé si nécessaire, agenda libre/occupé via l'interop Calendar.
7. Décommissionnement : conserver le tenant source en lecture quelques semaines, puis export légal.

12.3 Google Workspace -> M365 (sens inverse)

• Messagerie, agendas, contacts : migration native Exchange Online « Google Workspace » (lot de migration depuis le centre d'administration Exchange), qui s'appuie sur un compte de service Google avec délégation domain-wide et des scopes Gmail/Calendar/Contacts.
• Drive : SharePoint Migration Manager prend en charge Google Drive comme source (connexion via une application OAuth autorisée par un admin Google).
• Les documents Google natifs sont convertis en formats Office : contrôler la fidélité (formules Sheets, scripts Apps Script non migrés).
• Voir aussi Microsoft 365 / Exchange Online.

12.4 Contrôles post-migration

Contrôle	Moyen	Critère
Volumétrie mail	Rapport de l'outil de migration vs statistiques de la source (nombre d'éléments par boîte)	Écart < 1 % et expliqué (éléments corrompus, trop volumineux)
Volumétrie Drive	gam user x print filecounts côté Google vs inventaire source	Nombre de fichiers et taille cohérents
Flux entrants	Envoi de test depuis l'extérieur vers chaque domaine et alias	Réception, SPF/DKIM/DMARC pass dans les en-têtes
Flux sortants applicatifs	Copieurs, ERP, sites web via relais SMTP	Aucun rejet dans les journaux de livraison
Agendas et ressources	Réservation de salle, invitation récurrente	Récurrences et participants intacts
Partages	Échantillon de dossiers partagés par équipe	Membres et droits conformes au mapping
Clients	Postes et mobiles reconfigurés, ancien profil supprimé	Plus aucune connexion au système source dans ses journaux

13. Gestion avancée des appareils

13.1 Niveaux de gestion

Niveau	Agent	Capacités
Basique (mobile)	Aucun	Code de verrouillage, effacement du compte, inventaire
Avancé (mobile)	Android Device Policy / profil MDM iOS	Profil professionnel Android, applis gérées, effacement complet, approbation des appareils
Endpoint Verification	Extension Chrome + aide native	Inventaire et signaux de posture pour CAA
Windows (GCPW + gestion Windows)	Google Credential Provider for Windows	Connexion Windows avec compte Google, paramètres OMA-URI, BitLocker, mises à jour
ChromeOS	Inscription d'entreprise	Politiques complètes, mode kiosque, effacement

13.2 Bonnes pratiques

• Activer l'approbation des appareils pour les OU sensibles : un appareil n'accède aux données qu'après validation.
• Importer l'inventaire des appareils d'entreprise (numéros de série) pour que is_corp_owned_device soit vrai dans CAA.
• Android : imposer le profil professionnel sur les appareils personnels (séparation des données, effacement du seul profil).
• Postes Windows déjà gérés par Intune : ne pas superposer deux MDM ; utiliser Endpoint Verification pour les signaux et laisser Intune gérer (voir Intune).

13.3 GCPW sur Windows

Google Credential Provider for Windows permet d'ouvrir une session Windows avec le compte Google (y compris via SSO tiers selon configuration) et d'activer la gestion Windows depuis la console. Points de conception :

• Restreindre les domaines autorisés à la connexion (paramètre domains_allowed_to_login dans le registre lors de l'installation).
• Décider si les comptes créés sont administrateurs locaux (non par défaut recommandé) et prévoir LAPS ou équivalent pour le compte local de secours.
• Postes joints à un domaine AD : GCPW peut associer le compte Google au profil AD existant ; tester avant généralisation.
• BitLocker et mises à jour se pilotent depuis la console (gestion Windows) ; vérifier les paramètres disponibles, la liste évolue.

# Installation silencieuse (exemple, à adapter au MSI/EXE fourni par Google)
# puis restriction des domaines autorisés
reg add "HKLM\Software\Google\GCPW" /v domains_allowed_to_login /t REG_SZ /d "example.com" /f

# Vérifier l'enrôlement côté console : Appareils > Ordinateurs Windows

# Inventaire mobiles et ChromeOS
gam redirect csv ./mobiles.csv print mobile fields deviceid,email,model,os,status,lastsync,type
gam redirect csv ./cros.csv print cros fields serialnumber,orgunitpath,osversion,lastsync,annotateduser

# Appareils mobiles non synchronisés depuis 60 jours (filtrer le CSV), puis effacement du compte
gam update mobile <resourceId> action account_wipe

14. Sauvegarde tierce et responsabilité partagée

Google garantit la disponibilité et la durabilité de sa plateforme ; il ne protège pas contre une suppression légitime (utilisateur, admin, script, synchronisation), un rançongiciel qui chiffre le Drive via le client de synchronisation, une règle de rétention mal réglée ou la perte du compte administrateur. Fenêtres natives : corbeille Drive (30 jours), restauration admin des données d'un utilisateur (environ 25 jours après suppression définitive), restauration d'un compte supprimé (environ 20 jours).

14.1 Critères de choix d'une solution tierce

Critère	Question à poser
Périmètre	Gmail, Drive (Mon Drive + Drives partagés), Agenda, Contacts, Chat, Sites ? Permissions sauvegardées ?
Fréquence / RPO	Combien de passes par jour ? Incrémental réel ?
Restauration	À l'emplacement d'origine, vers un autre compte, export ; granularité (un message, un dossier) ?
Localisation	Stockage dans l'UE, chez qui, possibilité d'apporter son stockage (S3) ?
Sécurité	Chiffrement, clé client, immutabilité, MFA sur la console, compte de service dédié ?
Comptes sortants	Conservation des données d'un compte supprimé dans Google, et coût ?

Exemples de solutions du marché (SaaS ou auto-hébergées) : Spanning, Backupify, Afi, SysCloud, Synology Active Backup for Google Workspace, CubeBackup. Comparer sur les critères ci-dessus, pas sur la plaquette.

14.2 Solution DIY minimale : rclone avec impersonation

# rclone.conf - remote Drive avec compte de service délégué (scope drive.readonly)
[gdrive]
type = drive
scope = drive.readonly
service_account_file = /etc/rclone/sa-backup.json

# Copie du Drive d'un utilisateur vers un stockage chiffré (remote crypt défini ailleurs)
rclone copy gdrive: crypt-s3:gw/alice --drive-impersonate alice@example.com \
  --drive-export-formats docx,xlsx,pptx --fast-list --transfers 8 --log-file /var/log/rclone-gw.log

Limites : pas de permissions, pas de Gmail, conversion des documents natifs. C'est un filet de sécurité, pas une solution d'entreprise.

15. Multi-domaines, alias et routage

15.1 Domaine secondaire vs domaine alias

Type	Comportement	Quand l'utiliser
Domaine principal	Domaine du compte client, non renommable simplement	Nom de l'organisation pérenne
Domaine secondaire	Utilisateurs dont l'adresse principale est dans ce domaine	Filiales, marques avec identité propre
Domaine alias	Chaque utilisateur reçoit automatiquement prenom@alias.example	Ancien nom, variante orthographique, TLD supplémentaire

Chaque domaine nécessite son propre MX, SPF, DKIM (clé par domaine à générer dans Gmail > Authentifier les e-mails) et DMARC. Voir DKIM / DMARC.

15.2 Routage avancé Gmail

• Routage partagé (split delivery) : comptes inconnus de Google relayés vers un autre serveur (coexistence avec Exchange).
• Double distribution : copie vers un archivage ou un second système.
• Passerelle sortante / relais SMTP : pour les applications et copieurs, utiliser le service de relais SMTP avec authentification et restriction d'IP plutôt qu'un compte utilisateur avec mot de passe d'application.
• Passerelle entrante : si un filtre tiers est devant Gmail, déclarer ses IP pour que SPF/DMARC soient évalués correctement.

# Alias et groupes
gam create alias contact@example.com user alice@example.com
gam print aliases
gam info domain
gam print domains
gam print domainaliases

16. Dépannage et checklist sécurité

16.1 Symptôme -> cause -> correction

Symptôme	Cause probable	Correction
GAM : unauthorized_client sur une commande utilisateur	Scope non délégué ou mauvais ID client dans la délégation domain-wide	gam user admin@example.com check serviceaccount, recoller la liste de scopes
GAM : invalid_grant	Refresh token révoqué (changement de mot de passe, admin suspendu) ou horloge décalée	Resynchroniser NTP, gam oauth create
SSO : « 403 app_not_configured_for_user »	NameID différent de l'adresse Google	Corriger la revendication NameID côté IdP
SSO : boucle de redirection ou « signature invalide »	Certificat IdP renouvelé non importé côté Google	Importer le nouveau certificat dans le profil SSO
GCDS veut supprimer des centaines de comptes	Filtre LDAP vide ou compte LDAP expiré	Ne pas lancer -a ; corriger la requête ; abaisser le seuil de suppression
Utilisateurs bloqués après activation CAA	Endpoint Verification non déployé ou signaux non remontés	Repasser en mode surveillance, vérifier l'inventaire des appareils
Messages d'une application rejetés (DMARC)	Application qui envoie directement sans DKIM du domaine	Passer par le relais SMTP Google ou signer DKIM chez le prestataire
Données d'un ancien salarié introuvables dans Vault	Compte supprimé (données Vault supprimées avec lui)	Restauration du compte si < 20 jours ; sinon sauvegarde tierce ; corriger la procédure de départ
Export BigQuery vide	Droits du compte de service Google sur le dataset retirés	Rétablir les droits, réactiver l'export
Erreurs 429 / rateLimitExceeded en masse	Parallélisme excessif	Réduire num_threads de GAM, backoff exponentiel

16.2 Checklist sécurité du tenant

Domaine	Contrôle	Fréquence
Admins	2 à 4 super admins, clés FIDO2 obligatoires, rôles délégués pour le reste	Trimestrielle
Bris de glace	2 comptes, clés en coffre, alerte sur connexion, test tracé	Trimestrielle
2SV	Application obligatoire, SMS interdits, 100 % des comptes actifs inscrits	Mensuelle (rapport GAM)
Protocoles hérités	IMAP/POP désactivés ou restreints, mots de passe d'application interdits	À chaque changement
OAuth	Accès API restreint, liste d'applications de confiance revue, jetons audités	Mensuelle
Délégation domain-wide	Liste des clients délégués et de leurs scopes justifiée ; clés de SA tournées	Semestrielle
Gmail	Transfert externe automatique désactivé, protection avancée anti-hameçonnage et pièces jointes activée, DMARC en p=reject	Semestrielle
Drive	Partage externe restreint, audit des liens publics, Drives partagés verrouillés	Mensuelle
DLP / étiquettes	Règles actives, faux positifs revus	Trimestrielle
Vault	Règles de rétention validées par le juridique, accès Vault restreint, journal Vault revu	Semestrielle
Journaux	Export BigQuery/SIEM actif, rétention ≥ 1 an, alertes critiques routées	Mensuelle
Appareils	Gestion avancée, approbation, appareils inactifs effacés	Mensuelle
Cycle de vie	Procédure de départ scriptée, comptes inactifs > 90 j suspendus	Mensuelle
Sauvegarde	Solution tierce active, test de restauration réel documenté	Trimestrielle