Guide Complet d'Audit de Sécurité Google Workspace

1. Introduction & Philosophie de l'Audit

1.1 Pourquoi auditer Google Workspace ?

Google Workspace est devenu le système nerveux central de millions d'organisations : messagerie, stockage de fichiers, gestion des identités, collaboration en temps réel, et désormais intégrations d'intelligence artificielle. Cette centralisation offre un confort opérationnel indéniable mais crée une surface d'attaque massive et souvent sous-évaluée.

Contrairement à une infrastructure on-premise, la sécurité Google Workspace est une responsabilité partagée :

• Google est responsable de la sécurité de l'infrastructure (disponibilité, chiffrement au repos et en transit, physique des datacenters)
• L'organisation est entièrement responsable de la sécurité dans le tenant (configurations, droits d'accès, partages, applications tierces, politiques)

Cette limite est mal comprise par la majorité des équipes IT. Un audit Google Workspace vise précisément à évaluer la posture de sécurité dans ce périmètre de responsabilité organisationnelle.

1.2 Principes directeurs

Lecture seule absolue. Un audit ne doit jamais modifier la configuration d'un tenant de production. Toute action doit être réversible et tracée. Les techniques utilisées dans ce guide s'appuient exclusivement sur des APIs en lecture seule. Exhaustivité et priorisation. L'objectif n'est pas de lister des dizaines de findings sans impact, mais d'identifier les risques réels, de les quantifier et de les prioriser selon leur probabilité et leur impact métier. Reproductibilité. Chaque vérification décrite dans ce guide doit pouvoir être réalisée de manière identique par différents auditeurs sur différents tenants. Preuve par les données. Chaque finding doit être étayé par des données extraites des APIs Google, pas par des suppositions. La chaîne de preuves doit être documentée.

1.3 Types d'audit

1.3 Menaces spécifiques à Google Workspace

Comprendre le modèle de menace propre à Google Workspace est essentiel pour orienter les vérifications. Les vecteurs d'attaque les plus fréquemment observés en environnement Workspace sont :

1. Phishing de credentials Le phishing reste le vecteur initial le plus courant. Les attaquants créent des pages de connexion Google factices, souvent hébergées sur des domaines légitimes compromis ou des services cloud (Firebase, Cloudflare Workers). Le vol de cookies de session via des proxies AITM (Adversary-in-the-Middle) comme EvilGinx permet de contourner la 2FA classique (TOTP/SMS) en capturant à la fois les credentials et le cookie de session valide. 2. OAuth Consent Phishing L'attaquant enregistre une application OAuth malveillante et envoie à la victime un lien d'autorisation légitime (hébergé sur accounts.google.com). L'utilisateur pense autoriser un outil de productivité et accorde en réalité des droits Gmail ou Drive à une app contrôlée par l'attaquant. Le token OAuth créé persiste même après un changement de mot de passe. 3. Account Takeover via récupération Si l'email de récupération d'un compte Workspace est compromis (notamment via les milliers de breaches publiques), l'attaquant peut déclencher la procédure de récupération du compte Google et contourner la 2FA. C'est un vecteur sous-estimé mais très efficace, notamment via les stealer logs qui contiennent des mots de passe en clair. 4. Insider threat Un employé malveillant ou un ex-employé avec accès résiduel peut activer silencieusement un transfert Gmail, exporter massivement des fichiers Drive, ou créer un service account backdoor. La détection repose sur l'analyse comportementale des logs d'administration et d'accès. 5. Compromission de la chaîne logicielle (supply chain) Des applications OAuth légitimes utilisées par l'organisation peuvent elles-mêmes être compromises. Un attaquant qui prend le contrôle du serveur d'une app tierce hérite de tous les tokens OAuth accordés par les utilisateurs. La validation régulière des applications autorisées est critique. 6. Attaque sur les appareils BYOD non gérés Les utilisateurs accèdent à Gmail et Drive depuis des appareils personnels non gérés. Un malware info-stealer sur ces appareils capture les cookies de session Google, donnant à l'attaquant un accès authentifié sans besoin de credentials.

1.4 Rôles et responsabilités

---

2. Périmètre et Niveaux d'Audit

2.1 Périmètre technique

Un audit Google Workspace complet couvre les composants suivants :

┌─────────────────────────────────────────────────────────────────┐
│                    GOOGLE WORKSPACE TENANT                      │
│                                                                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │   IAM &     │  │    Gmail    │  │   Google    │            │
# ... (extrait — voir documentation officielle)

2.2 Matrice de couverture par niveau

---

3. Prérequis et Infrastructure d'Audit

3.1 Compte requis côté client

Pour réaliser un audit complet via APIs, il faut :

1. Un compte Super Admin Google Workspace appartenant à l'organisation auditée — pour créer le Service Account et configurer la délégation
2. Un projet Google Cloud Platform (GCP) — pour héberger le Service Account

En lecture seule, le risque pour le tenant est nul. La clé de service account doit rester strictement confidentielle et être révoquée à la fin de l'audit.

3.2 Création du projet GCP et du Service Account

Étape 1 — Créer le projet GCP

# Via gcloud CLI (ou depuis console.cloud.google.com)
gcloud projects create audit-workspace-YYYYMMDD \
  --name="Audit Workspace"

gcloud config set project audit-workspace-YYYYMMDD

Étape 2 — Créer le Service Account

gcloud iam service-accounts create audit-sa \
  --description="Service Account lecture seule pour audit Workspace" \
  --display-name="Audit Service Account"

# Créer la clé JSON
# ... (extrait — voir documentation officielle)

Étape 3 — Activer les APIs nécessaires

# APIs essentielles
gcloud services enable admin.googleapis.com
gcloud services enable gmail.googleapis.com
gcloud services enable drive.googleapis.com
gcloud services enable calendar-json.googleapis.com
# ... (extrait — voir documentation officielle)

Étape 4 — Configurer la Domain-Wide Delegation

Dans admin.google.com → Sécurité → Contrôles et données d'accès → Contrôle des API → Délégation au niveau du domaine :

Ajouter le Client ID du Service Account avec les scopes suivants (en une seule ligne, séparés par des virgules) :

https://www.googleapis.com/auth/admin.reports.audit.readonly,
https://www.googleapis.com/auth/admin.reports.usage.readonly,
https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/admin.directory.group.readonly,
https://www.googleapis.com/auth/admin.directory.domain.readonly,
# ... (extrait — voir documentation officielle)

Attention : Copier-coller les scopes sans espaces parasites. Une erreur fréquente est l'introduction d'espaces entre les scopes qui empêche la validation silencieusement.

3.3 Configuration Python de base

# config.py
DOMAIN = "exemple.com"
SERVICE_ACCOUNT_KEY = "audit-key.json"
ADMIN_EMAIL = "admin@exemple.com"  # Email d'un Super Admin pour l'impersonation

# ... (extrait — voir documentation officielle)

# auth.py
from google.oauth2 import service_account
from googleapiclient.discovery import build
from config import SERVICE_ACCOUNT_KEY, ADMIN_EMAIL, SCOPES

# ... (extrait — voir documentation officielle)

3.4 Prérequis techniques auditeur

pip install google-api-python-client google-auth dnspython requests rich

3.5 Synchronisation de l'horloge (critique)

Les tokens OAuth nécessitent une horloge système synchronisée. Une dérive de plus de 5 minutes provoque des erreurs invalid_grant. Avant tout audit :

# Linux/macOS
sudo ntpdate -u pool.ntp.org

# Windows (PowerShell admin)
w32tm /resync /force
# ... (extrait — voir documentation officielle)

---

---

4. Niveau 1 — Identités, Accès et Authentification

4.1 Inventaire des utilisateurs

La première étape est d'obtenir la liste exhaustive des utilisateurs et leurs attributs de sécurité.

def get_all_users(service):
    """Retourne tous les utilisateurs du domaine avec leurs attributs de sécurité."""
    users = []
    page_token = None
    while True:
# ... (extrait — voir documentation officielle)

Attributs à extraire et analyser :

4.2 Analyse des comptes Super Admin

Le CIS Benchmark recommande un maximum de 4 Super Admins (idéalement 2-3). Chaque compte Super Admin compromis donne un accès total au tenant.

Points de contrôle :

• Nombre de Super Admins (≤ 4)
• Les Super Admins utilisent-ils des comptes dédiés (non utilisés au quotidien) ?
• Chaque Super Admin dispose-t-il d'une clé de sécurité physique (FIDO2/YubiKey) ?
• Les Super Admins ont-ils des emails de récupération internes au domaine ?

def audit_super_admins(users):
    super_admins = [u for u in users if u.get("isAdmin")]
    risks = []
    for sa in super_admins:
        recovery = sa.get("recoveryEmail", "")
# ... (extrait — voir documentation officielle)

4.3 Analyse de la 2FA

Distinction cruciale : Il existe une différence entre 2FA enrollée (l'utilisateur a configuré un second facteur) et 2FA enforced (la politique admin oblige la 2FA — un utilisateur ne peut pas la désactiver).

def audit_2fa(users):
    findings = {
        "no_2fa": [],           # Aucune 2FA configurée
        "enrolled_not_enforced": [],  # 2FA configurée mais pas obligatoire
        "fully_enforced": [],   # 2FA enforced
# ... (extrait — voir documentation officielle)

Types de 2FA — Résistance au phishing :

4.4 Emails de récupération — Vecteur d'account takeover

L'email de récupération est le talon d'Achille de la 2FA. Si l'email de récupération est compromis, un attaquant peut réinitialiser le mot de passe sans avoir besoin de la 2FA. C'est le vecteur d'attaque le plus sous-estimé en environnement Workspace.

def audit_recovery_info(service, user_emails):
    findings = {
        "external_recovery_emails": [],
        "external_recovery_phones": [],
        "no_recovery": [],
# ... (extrait — voir documentation officielle)

Critères de risque pour les emails de récupération :

4.5 Comptes inactifs et suspendus

Un compte inactif non supprimé représente un vecteur d'attaque persistant. Les comptes suspendus non traités signalent l'absence d'une procédure d'offboarding.

from datetime import datetime, timezone, timedelta

def audit_inactive_accounts(users, inactive_days=90):
    threshold = datetime.now(timezone.utc) - timedelta(days=inactive_days)
    inactive = []
# ... (extrait — voir documentation officielle)

4.6 Rôles administratifs

Google Workspace permet de déléguer des rôles granulaires (admin messagerie, admin helpdesk, etc.). Un audit doit lister tous les rôles administratifs et vérifier le respect du principe du moindre privilège.

def audit_admin_roles(service):
    """Liste tous les rôles et leurs assignations."""
    roles = service.roles().list(customer="my_customer").execute()
    role_assignments = service.roleAssignments().list(
        customer="my_customer"
# ... (extrait — voir documentation officielle)

---

5. Niveau 2 — Messagerie Gmail

5.1 Transferts automatiques

Le transfert automatique de messagerie est l'un des risques les plus graves : il crée une exfiltration de données en temps réel, silencieuse et persistante. À auditer sur tous les comptes.

def audit_gmail_forwarding(gmail_service, user_email):
    """Vérifie si un utilisateur a configuré un transfert automatique."""
    try:
        settings = gmail_service.users().settings().getAutoForwarding(
            userId=user_email
# ... (extrait — voir documentation officielle)

Contre-mesures :

• Désactiver le transfert automatique pour tous les utilisateurs via la politique admin
• Chemin : admin.google.com → Apps → Gmail → Paramètres utilisateur → Transfert automatique de courrier
• Activer des alertes sur toute activation de transfert

5.2 Délégation de boîte mail

La délégation permet à un utilisateur de gérer la boîte d'un autre. C'est une fonctionnalité légitime (assistante/dirigeant) mais qui crée une surface d'attaque si mal configurée.

def audit_gmail_delegation(gmail_service, user_email):
    """Liste les délégations actives sur un compte."""
    try:
        delegates = gmail_service.users().settings().delegates().list(
            userId=user_email
# ... (extrait — voir documentation officielle)

5.3 Filtres Gmail avec actions de redirection

Les filtres Gmail peuvent rediriger silencieusement certains emails vers des adresses externes. Moins visibles que le transfert automatique, ils représentent un risque d'exfiltration ciblée.

def audit_gmail_filters(gmail_service, user_email):
    """Détecte les filtres avec redirection vers l'extérieur."""
    risky_filters = []
    try:
        filters = gmail_service.users().settings().filters().list(
# ... (extrait — voir documentation officielle)

5.4 Tokens de session actifs (App Passwords)

Les App Passwords (anciennement "Less Secure Apps") permettent un accès IMAP/POP3 sans 2FA. Leur présence signale qu'un client mail ancien (Outlook, Thunderbird en mode IMAP basique) accède au compte en contournant la 2FA.

def audit_app_passwords(security_service, user_email):
    """Détecte les App Passwords (Less Secure Apps)."""
    try:
        asps = security_service.asps().list(userKey=user_email).execute()
        items = asps.get("items", [])
# ... (extrait — voir documentation officielle)

---

---

6. Niveau 3 — Google Drive et Partages

6.1 Partages publics ("Anyone with link")

Un fichier partagé avec "Tout le monde avec le lien" est accessible sans authentification. N'importe qui possédant le lien peut accéder au contenu, et ce lien peut circuler indéfiniment.

def audit_public_files(drive_service, user_email):
    """Trouve les fichiers accessibles publiquement."""
    public_files = []
    page_token = None
    while True:
# ... (extrait — voir documentation officielle)

6.2 Partages externes

Les partages avec des utilisateurs hors domaine doivent être inventoriés. Les points d'attention sont :

• Volume total de partages externes
• Destinataires récurrents (identifier les partenaires vs les erreurs)
• Permissions accordées (WRITER est plus risqué que READER)
• Absence de date d'expiration

def audit_external_shares(drive_service, domain):
    """Identifie tous les partages vers des utilisateurs extérieurs au domaine."""
    external = []
    page_token = None
    while True:
# ... (extrait — voir documentation officielle)

6.3 Analyse volumétrique des fichiers

L'analyse volumétrique permet d'identifier des anomalies : dumps de base de données, archives de données sensibles, doublons massifs, fichiers anciens oubliés.

SENSITIVE_KEYWORDS = [
    "bulletin", "paie", "salaire", "contrat", "password", "mdp", "credential",
    "dump", "backup", "bak", "export", "confidentiel", "secret", "budget",
    "bilan", "paierol", "rh", "ressources-humaines",
]
# ... (extrait — voir documentation officielle)

Indicateurs à surveiller :

6.4 Service Accounts avec accès Drive

Des service accounts GCP (souvent créés pour des automatisations ou des applications tierces) peuvent avoir des accès en écriture sur des fichiers Drive. Ce vecteur est souvent oublié.

def detect_service_account_shares(permissions):
    """Détecte les partages avec des service accounts GCP."""
    sa_shares = []
    for perm in permissions:
        email = perm.get("emailAddress", "")
# ... (extrait — voir documentation officielle)

---

7. Niveau 4 — DNS et Sécurité Email

7.1 SPF — Sender Policy Framework

Le SPF définit quels serveurs sont autorisés à envoyer des emails au nom du domaine.

import dns.resolver

def check_spf(domain):
    """Vérifie et analyse l'enregistrement SPF."""
    try:
# ... (extrait — voir documentation officielle)

Niveaux SPF et impact :

7.2 DKIM — DomainKeys Identified Mail

DKIM ajoute une signature cryptographique aux emails sortants, permettant au destinataire de vérifier que le message n'a pas été altéré.

def check_dkim(domain, selector="google"):
    """Vérifie l'enregistrement DKIM pour le sélecteur spécifié."""
    try:
        dkim_record = f"{selector}._domainkey.{domain}"
        answers = dns.resolver.resolve(dkim_record, "TXT")
# ... (extrait — voir documentation officielle)

7.3 DMARC — Domain-based Message Authentication

DMARC définit quoi faire des emails qui échouent SPF et DKIM, et où envoyer les rapports.

def check_dmarc(domain):
    """Vérifie et analyse la politique DMARC."""
    try:
        dmarc_record = f"_dmarc.{domain}"
        answers = dns.resolver.resolve(dmarc_record, "TXT")
# ... (extrait — voir documentation officielle)

Chemin de maturation DMARC recommandé :

Phase 1 (Observation) : p=none ; rua=mailto:dmarc@votredomaine.com
    ↓ (2-4 semaines d'analyse des rapports)
Phase 2 (Durcissement) : p=quarantine ; pct=10 → pct=100
    ↓ (2-4 semaines de validation)
Phase 3 (Protection complète) : p=reject

7.4 Enregistrements MX et blacklists

def check_mx_blacklists(domain):
    """Vérifie si les serveurs MX sont sur des blacklists email."""
    blacklists = [
        "zen.spamhaus.org",
        "bl.spamcop.net",
# ... (extrait — voir documentation officielle)

---

8. Niveau 5 — Applications OAuth et Intégrations Tierces

8.1 Inventaire des tokens OAuth

Chaque fois qu'un utilisateur autorise une application tierce ("Connexion avec Google"), un token OAuth est créé. Ces tokens accordent des droits sur les données de l'utilisateur selon les scopes demandés.

SCOPE_RISK_LEVELS = {
    "https://mail.google.com/": ("CRITIQUE", "Accès complet Gmail (lecture + modification + suppression)"),
    "https://www.googleapis.com/auth/gmail.modify": ("ÉLEVÉ", "Modification des emails Gmail"),
    "https://www.googleapis.com/auth/drive": ("CRITIQUE", "Accès complet Google Drive"),
    "https://www.googleapis.com/auth/drive.file": ("MOYEN", "Fichiers Drive créés par l'app"),
# ... (extrait — voir documentation officielle)

8.2 Gouvernance des applications OAuth

Politique de whitelisting — Sans liste blanche, tout utilisateur peut autoriser n'importe quelle application OAuth. Cette configuration est la source de nombreux incidents de phishing OAuth ("consent phishing"). Configuration recommandée dans admin.google.com :

Admin Console → Sécurité → Contrôle des API → Contrôle d'accès aux applications Google
→ Activer : "Seules les apps approuvées par l'administrateur peuvent accéder aux données"
→ Créer une liste blanche des applications autorisées

Signaux d'alerte sur un token OAuth :

• Application avec un clientId inconnu ou non documenté
• Scope mail.google.com accordé à une app non-Google
• Tokens anonymes (apps non identifiables publiquement)
• Nombre de tokens excessif pour un seul utilisateur (> 20)
• Applications de type "AI" avec accès Drive/Gmail complet

8.3 Cas particulier — Outils d'IA et données d'entreprise

Avec la prolifération des outils d'IA (Gemini, Copilot, Claude, ChatGPT via plugins), il est fréquent de trouver des tokens OAuth accordant accès à des volumes importants de données d'entreprise. Ces accès posent des questions :

• Les CGU du fournisseur permettent-elles l'entraînement sur les données ?
• Un DPA (Data Processing Agreement) existe-t-il avec le fournisseur d'IA ?
• Les données personnelles de tiers (clients, employés) transitent-elles par ces services ?

Contrôle à réaliser : Lister toutes les applications OAuth contenant "AI", "GPT", "Gemini", "Claude", "Assistant" dans leur nom, et vérifier les scopes accordés.

---

---

9. Niveau 6 — Appareils Mobiles et Points de Terminaison

9.1 Inventaire MDM

Google Workspace intègre une gestion basique des appareils mobiles (MDM). L'audit MDM révèle souvent des appareils fantômes ou des appareils BYOD non gérés.

def audit_mobile_devices(service):
    """Inventaire complet des appareils mobiles enregistrés."""
    devices = []
    page_token = None
    while True:
# ... (extrait — voir documentation officielle)

Points critiques :

• Appareils non synchronisés depuis > 6 mois : fantômes à supprimer
• Appareils BYOD appartenant à des Super Admins : risque élevé
• Appareils sans chiffrement activé
• Absence de PIN obligatoire
• Absence de remote wipe configuré

9.2 Configuration MDM recommandée

Politique minimale pour les appareils accédant aux données d'entreprise :

---

10. Niveau 7 — Groupes et Politiques de Partage

10.1 Audit des groupes

def audit_groups(service, groups_settings_service):
    """Analyse la sécurité des groupes Google."""
    findings = {
        "total_groups": 0,
        "external_members": [],
# ... (extrait — voir documentation officielle)

10.2 Politiques de partage global

Paramètres à vérifier dans admin.google.com → Drive → Partage :

---

11. Niveau 8 — Journalisation, Alertes et Surveillance

11.1 Alert Center

L'Alert Center Google Workspace centralise les alertes de sécurité du tenant.

def audit_alert_center(service, days=90):
    """Récupère et analyse les alertes du Alert Center."""
    from datetime import datetime, timezone, timedelta
    import json

# ... (extrait — voir documentation officielle)

11.2 Logs de connexion

def audit_login_logs(service, days=30):
    """Analyse les logs de connexion pour détecter des comportements suspects."""
    from datetime import datetime, timezone, timedelta

    start = (datetime.now(timezone.utc) - timedelta(days=days)).isoformat() + "Z"
# ... (extrait — voir documentation officielle)

Comportements suspects à surveiller :

• Connexions depuis des pays inhabituels (géolocalisation des IPs)
• Connexions à des heures anormales (2h-5h du matin pour une organisation française)
• Pic d'échecs de connexion sur un compte (> 5 en 24h = brute force potentiel)
• Connexions simultanées depuis des localisations géographiquement impossibles
• Super Admins avec des échecs de connexion répétés

11.3 Logs d'administration

def audit_admin_logs(service, days=30):
    """Analyse les actions d'administration des 30 derniers jours."""
    SENSITIVE_ACTIONS = [
        "CHANGE_USER_PASSWORD",
        "CHANGE_RECOVERY_EMAIL",
# ... (extrait — voir documentation officielle)

11.4 Alertes recommandées à configurer

Dans admin.google.com → Sécurité → Alertes → Créer des alertes :

---

12. Niveau 9 — Reconnaissance Passive et Threat Intelligence

12.1 Certificate Transparency (crt.sh)

Les Certificate Transparency Logs enregistrent tous les certificats TLS émis. Ils permettent de découvrir des sous-domaines non documentés.

import requests

def check_certificate_transparency(domain):
    """Découverte de sous-domaines via Certificate Transparency Logs."""
    try:
# ... (extrait — voir documentation officielle)

Sous-domaines à risque à rechercher :

12.2 Google Dorks — Recherche de données exposées

Les Google Dorks permettent de chercher des données spécifiques indexées par Google. À exécuter manuellement dans un navigateur (les requêtes automatiques violent les ToS Google).

# Documents confidentiels indexés
site:votredomaine.com filetype:pdf "confidentiel"
site:votredomaine.com filetype:xlsx OR filetype:csv

# Documents Google Drive publics
# ... (extrait — voir documentation officielle)

12.3 Shodan — Exposure Internet

Shodan indexe les services Internet exposés. Sans clé API, l'API gratuite internetdb.shodan.io donne des informations de base.

def check_shodan_free(ip):
    """Interroge l'API Shodan InternetDB (gratuite, sans clé)."""
    try:
        resp = requests.get(
            f"https://internetdb.shodan.io/{ip}",
# ... (extrait — voir documentation officielle)

Tags Shodan critiques :

• eol-product : logiciel en fin de vie (PHP 7.x, Apache 2.2, etc.)
• self-signed : certificat auto-signé
• starttls : chiffrement opportuniste (non forcé)
• vpn : service VPN exposé

12.4 HIBP — Have I Been Pwned

HIBP permet de vérifier si des emails d'une organisation apparaissent dans des bases de données de credentials compromis.

def check_hibp_domain(domain, api_key):
    """Vérifie via l'API HIBP Domain Search tous les emails d'un domaine."""
    headers = {
        "hibp-api-key": api_key,
        "User-Agent": "Security-Audit-Tool",
# ... (extrait — voir documentation officielle)

Interprétation des breaches HIBP :

Automatisation de la vérification HIBP

Pour les organisations avec une clé API HIBP, la vérification peut être automatisée sur l'ensemble du domaine :

import requests, time

def hibp_domain_search(domain, api_key):
    """
    HIBP Domain Search — retourne tous les emails compromis du domaine.
# ... (extrait — voir documentation officielle)

Corrélation critique : Toujours croiser les emails compromis HIBP avec :

1. Leur rôle dans l'organisation (Super Admin = risque maximal)
2. La présence d'un email de récupération externe
3. Le type de breach (stealer log vs. scraping public)

---

---

13. Niveau 10 — Conformité Réglementaire

13.1 Conformité RGPD

Le RGPD impose des obligations précises sur la gestion des données personnelles. Un audit Google Workspace doit évaluer la conformité article par article.

Articles RGPD directement impactés par la configuration Workspace :

def calculate_gdpr_score(findings):
    """Calcule un score de conformité RGPD basé sur les findings."""
    score = 100
    violations = []

# ... (extrait — voir documentation officielle)

13.2 Conformité NIS2

La directive NIS2 s'applique aux entités importantes et essentielles, notamment les ESN/prestataires IT. Les obligations clés à auditer :

13.3 CIS Benchmark Google Workspace

Le Center for Internet Security publie un benchmark de sécurité spécifique à Google Workspace. Voir la Section 16 pour le détail complet.

Score CIS = nombre de contrôles conformes / total des contrôles évalués

Un score < 50% indique une posture de sécurité insuffisante.

---

14. Automatisation et Outillage

14.1 Architecture du framework d'audit

audit-workspace/
├── config.py              # Configuration centralisée
├── auth.py                # Authentification Service Account
├── main.py                # Orchestrateur principal
├── run_full_audit.py      # Exécution de tous les modules
# ... (extrait — voir documentation officielle)

14.2 Orchestrateur principal

# run_full_audit.py
import os, sys, json
os.environ["PYTHONUTF8"] = "1"

from auth import get_directory_service, get_reports_service
# ... (extrait — voir documentation officielle)

14.3 Gestion des erreurs courantes

---

15. Rapport et Feuille de Route

15.1 Structure du rapport

Un rapport d'audit Google Workspace complet doit contenir :

1. Synthèse Exécutive (1 page)
   - Score global de sécurité
   - Top 5 risques immédiats
   - Métriques clés

# ... (extrait — voir documentation officielle)

15.2 Scoring de sécurité

def calculate_security_score(findings):
    """Calcule un score de sécurité global de 0 à 100."""
    score = 100
    deductions = {
        "no_2fa_users": (-5, "par utilisateur sans 2FA"),
# ... (extrait — voir documentation officielle)

Grille d'interprétation du score :

15.3 Matrice de priorisation

Priorité = f(Impact, Probabilité, Effort de correction)

P1 (Immédiat) : Impact CRITIQUE + Probabilité HAUTE + Effort FAIBLE
P2 (J+7)      : Impact ÉLEVÉ  + Probabilité MOYENNE + Effort MOYEN
P3 (J+30)     : Impact MOYEN  + Probabilité BASSE   + Effort ÉLEVÉ
P4 (J+90)     : Gouvernance, processus, formation

15.4 Chemins d'attaque types

Kill Chain 1 — Exfiltration via forwarding Gmail

Phishing ou insider malveillant
→ Activation d'un transfert automatique Gmail
→ Copie en temps réel de tous les emails vers un tiers
→ Fuite continue de données confidentielles
→ Impact : RGPD, concurrentiel, contractuel

Kill Chain 2 — Account Takeover via email de récupération

Email de récupération présent dans un stealer log
→ Attaquant accède au compte Gmail/Yahoo de récupération
→ Procédure "mot de passe oublié" sur le compte Workspace
→ Bypass de la 2FA via le code envoyé sur l'email compromis
→ Accès complet au compte (emails, Drive, calendrier)
→ Escalade si compte Super Admin

Kill Chain 3 — OAuth Consent Phishing

Email malveillant : "Autorisez cette app pour accéder à votre planning"
→ Utilisateur clique et autorise l'app OAuth
→ L'app obtient les scopes accordés (Gmail, Drive)
→ Exfiltration silencieuse continue
→ Aucune trace dans les logs Gmail standards
→ Persiste même après changement de mot de passe

Kill Chain 4 — Compromission via service account externe

Clé de service account externe volée ou fuitée
→ Accès aux fichiers Drive partagés avec ce SA
→ Lecture de données confidentielles
→ Injection de code malveillant dans des scripts partagés
→ Exécution par un employé → RCE sur son poste
→ Pivot vers le réseau interne

---

16. Référentiel CIS Benchmark Google Workspace

Le CIS Benchmark for Google Workspace définit 40+ contrôles de sécurité. Voici les contrôles les plus critiques avec leur méthode de vérification :

Section 1 — Gestion des Identités et des Accès

Section 2 — Google Drive

Section 3 — Gmail

Section 4 — Sécurité Email DNS

Section 5 — Applications Tierces

Section 6 — Appareils Mobiles

Section 7 — Groupes

Section 8 — Journalisation

---

17. Annexes Techniques

Annexe A — Scopes OAuth par module d'audit

Annexe B — Commandes de référence rapide

# Lancer l'audit complet
python -X utf8 run_full_audit.py

# Lancer un module spécifique
python -X utf8 -c "from audit_users import *; print(audit_all_users())"
# ... (extrait — voir documentation officielle)

Annexe C — Checklist d'audit condensée

Avant l'audit :

• [ ] Service Account créé et clé JSON générée
• [ ] APIs GCP activées (Admin SDK, Gmail, Drive, Calendar, Alert Center)
• [ ] Domain-Wide Delegation configurée sans espaces dans les scopes
• [ ] Horloge système synchronisée
• [ ] Environnement Python configuré (PYTHONUTF8=1)

Pendant l'audit — Module IAM :

• [ ] Nombre de Super Admins (≤ 4 recommandé)
• [ ] 2FA enrollée et enforced sur tous les comptes
• [ ] Emails de récupération internes ou absents
• [ ] Comptes inactifs > 90 jours identifiés
• [ ] Comptes suspendus avec offboarding documenté

Pendant l'audit — Module Gmail :

• [ ] Aucun transfert automatique actif
• [ ] Aucune délégation externe
• [ ] Aucun App Password actif
• [ ] Filtres Gmail avec actions de redirection revus

Pendant l'audit — Module Drive :

• [ ] Fichiers publics ("anyone with link") inventoriés
• [ ] Partages externes documentés et justifiés
• [ ] Service accounts tiers avec accès Drive identifiés
• [ ] Fichiers sensibles inventoriés (RH, paie, BDD)

Pendant l'audit — Module DNS :

• [ ] SPF -all (hard fail)
• [ ] DKIM actif (2048 bits recommandé)
• [ ] DMARC p=reject avec reporting
• [ ] IP MX non listées sur blacklists

Pendant l'audit — Module OAuth :

• [ ] Volume de tokens par utilisateur
• [ ] Scopes accordés (Gmail complet, Drive complet = CRITIQUE)
• [ ] Applications AI avec accès données d'entreprise

Pendant l'audit — Module Recon :

• [ ] Sous-domaines via crt.sh
• [ ] Serveurs exposés (Shodan)
• [ ] Emails compromis (HIBP)
• [ ] Emails de récupération dans stealer logs

Post-audit :

• [ ] Clé Service Account révoquée
• [ ] Délégation domain-wide retirée
• [ ] Rapport livré et discuté
• [ ] Roadmap validée avec le client

Annexe D — Audit Google Chat et Meet

Google Chat est souvent négligé dans les audits alors qu'il constitue un canal de communication sensible et un vecteur de partage de données non maîtrisé.

D.1 Risques spécifiques à Google Chat

D.2 Vérifications Chat via admin.google.com

Admin Console → Apps → Google Workspace → Chat
→ Paramètres Chat :
   - Autoriser les utilisateurs externes dans les espaces : À restreindre
   - Historique par défaut : Configurer la rétention
   - Bots : Vérifier la liste des bots autorisés
   - Imports de fichiers : Vérifier les types autorisés

D.3 Audit Google Meet

Recommandation : Activer systématiquement le lobby pour les réunions avec des participants externes. Restreindre l'enregistrement aux utilisateurs authentifiés du domaine.

---

Annexe E — Intégration SIEM et Monitoring Continu

Un audit ponctuel fournit une photographie de la posture de sécurité à un instant T. Pour une protection continue, il est essentiel d'exporter les logs Google Workspace vers un SIEM.

E.1 Options d'export des logs

E.2 Logs prioritaires à collecter

# Applications prioritaires dans l'API Reports
LOG_APPLICATIONS = [
    "login",          # Connexions : succès, échecs, suspicions
    "admin",          # Actions admin : droits, configurations
    "drive",          # Accès fichiers : téléchargements, partages
# ... (extrait — voir documentation officielle)

E.3 Règles de détection recommandées

# Exemples de règles SIEM pour Google Workspace

Rule: Super Admin Login Outside Business Hours
  Source: login logs
  Condition: actor.isAdmin = true AND hour(timestamp) NOT IN (8..20)
# ... (extrait — voir documentation officielle)

E.4 Métriques de maturité SOC pour Workspace

---

Annexe F — Politique de Mots de Passe et Authentification Avancée

F.1 Vérification de la politique de mots de passe

La politique de mots de passe Workspace se configure dans admin.google.com → Sécurité → Authentification → Politique de mots de passe. Elle n'est pas accessible via API, mais les paramètres à vérifier manuellement sont :

Pourquoi désactiver l'expiration avec MFA fort ? Les recherches du NIST (SP 800-63B) montrent que l'expiration forcée des mots de passe conduit les utilisateurs à choisir des mots de passe prévisibles (ex: MotDePasse2025! → MotDePasse2026!). Avec un MFA résistant au phishing (FIDO2), la résilience vient du second facteur, pas de la rotation du premier.

F.2 Context-Aware Access

Context-Aware Access permet de conditionner l'accès aux services Google à des critères contextuels (localisation géographique, appareil géré, plage horaire).

Cas d'usage recommandés :

Politique 1 : Accès admin depuis appareils gérés uniquement
  Condition : isAdminUser = true
  Exigence : deviceManagementLevel = MANAGED
  Action si non conforme : Bloquer

# ... (extrait — voir documentation officielle)

F.3 Passkeys et FIDO2

Les passkeys remplacent le mot de passe par une paire de clés cryptographiques stockées sur l'appareil. Elles sont résistantes au phishing car liées au domaine lors de la création.

Déploiement progressif recommandé :

Phase 1 : Déployer les clés physiques FIDO2 (YubiKey 5 NFC) pour les Super Admins
          → Blocage complet de toute connexion sans clé physique

Phase 2 : Activer les passkeys pour les utilisateurs à haut risque
          → Dirigeants, équipes financières, équipes IT
# ... (extrait — voir documentation officielle)

---

Annexe G — Gestion des Incidents liés à Workspace

G.1 Procédure d'urgence — Compte compromis

DÉTECTION
└── Alerte Google, signalement utilisateur, ou détection SOC
        ↓
CONFINEMENT IMMÉDIAT (< 15 minutes)
└── 1. Révoquer toutes les sessions actives
# ... (extrait — voir documentation officielle)

G.2 Indicateurs de Compromission (IoC) spécifiques Workspace

G.3 Commandes d'urgence — Réponse rapide

# Révoquer toutes les sessions d'un utilisateur (lecture + écriture requise)
def revoke_all_sessions(service, user_email):
    """ATTENTION : Action d'écriture — à utiliser en cas d'incident confirmé."""
    service.users().signOut(userKey=user_email).execute()

# ... (extrait — voir documentation officielle)

---

Annexe H — Scoring et Benchmarking

H.1 Grille de scoring détaillée

La pondération ci-dessous reflète l'impact réel des contrôles sur la posture de sécurité :

H.2 Comparaison sectorielle

H.3 Évolution et suivi dans le temps

Un audit unique n'a que peu de valeur sans suivi. Les indicateurs à suivre trimestriellement :

Tableau de bord trimestriel Google Workspace
┌─────────────────────────────────────────────┐
│ Score global de sécurité         : [  /100] │
│ Conformité CIS Benchmark         : [  %   ] │
│ Emails compromis HIBP (domaine)  : [  /55 ] │
# ... (extrait — voir documentation officielle)

Annexe D — Ressources et Références

Annexe E — Modèle de feuille de route

---

---

Conclusion — Vers une Sécurité Google Workspace Durable

L'audit Google Workspace n'est pas une fin en soi : c'est le point de départ d'un programme de sécurité continu. Les organisations qui traitent cet exercice comme une vérification annuelle ponctuelle resteront exposées entre deux audits. Celles qui intègrent les contrôles automatisés, le monitoring continu et la culture de sécurité dans leur ADN réduiront durablement leur surface d'attaque.

Les cinq leviers de la maturité Workspace

1. L'identité comme périmètre de sécurité Dans un monde où les données résident dans le cloud, le périmètre réseau traditionnel n'existe plus. L'identité — et sa protection via 2FA résistant au phishing, Context-Aware Access, et gestion rigoureuse des comptes — est le nouveau périmètre. Investir prioritairement sur l'IAM est le levier à plus fort retour sur investissement. 2. La gouvernance des données avant la technologie Les technologies de protection (DLP, CASB, SIEM) sont efficaces uniquement si la gouvernance des données est en place : qui a accès à quoi, pour quels usages, pour quelle durée. Un Drive mal gouverné avec 200 000 fichiers partagés ne sera pas sécurisé par un outil — il faut d'abord définir et appliquer des politiques. 3. La détection comme complément à la prévention Aucun contrôle préventif n'est infaillible. La capacité à détecter rapidement une compromission — via des logs centralisés, des alertes bien configurées, et des procédures de réponse testées — réduit considérablement l'impact d'un incident. Le délai moyen de détection d'une compromission est encore de plusieurs semaines dans la majorité des organisations. 4. La sensibilisation des utilisateurs La grande majorité des incidents Workspace commence par une action humaine : cliquer sur un lien de phishing, autoriser une app OAuth malveillante, partager un document par erreur. Les contrôles techniques réduisent la surface d'attaque, mais la sensibilisation régulière des utilisateurs — notamment aux simulations de phishing, aux bonnes pratiques de partage Drive et à la reconnaissance des apps OAuth suspectes — reste indispensable. 5. La continuité de l'amélioration La sécurité n'est pas un état stable : le tenant évolue, de nouveaux utilisateurs arrivent, de nouvelles apps sont autorisées, de nouvelles vulnérabilités sont découvertes. Un audit annuel minimum, un monitoring continu des indicateurs clés, et une revue trimestrielle des accès (OAuth, partages Drive, Super Admins) constituent le rythme minimal d'un programme de sécurité Workspace sérieux.

Priorités universelles — Quel que soit le tenant

Quelle que soit la taille de l'organisation ou son niveau de maturité initial, trois actions produisent le plus grand effet de protection en un minimum de temps :

1. Enforcer la 2FA sur tous les comptes, sans exception
   → Réduit de 99% le risque d'account takeover par credential stuffing

2. Supprimer ou remplacer par des emails internes
   tous les emails de récupération externes sur les comptes admins
# ... (extrait — voir documentation officielle)

Ces trois contrôles, appliqués en moins d'une heure par un Super Admin, ferment les trois vecteurs d'attaque les plus fréquents et les plus dommageables sur Google Workspace.

---

Guide d'Audit Google Workspace — Version 1.0 — Mars 2026 Rédigé pour les équipes Sécurité et GRC — Reproduction autorisée à des fins internes

Conclusion

Ce guide opérationnel constitue une base de référence. Pour aller plus loin avec un accompagnement personnalisé, contactez notre équipe.