Chapitre 1

Introduction, Périmètre & Prérequis

Philosophie de l'audit Google Workspace, modèle de responsabilité partagée, périmètre technique des 10 niveaux et infrastructure de mise en place du compte de service GCP.

Ce chapitre couvre

Introduction, philosophie d'audit, périmètre et infrastructure technique

Section 1 — Introduction Section 2 — Périmètre Section 3 — Prérequis

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

Type	Durée	Profondeur	Cas d'usage
Audit flash	2-4h	IAM + Gmail + DNS	Vérification rapide avant incident
Audit standard	1-2 jours	Tous niveaux 1-7	Audit annuel de conformité
Audit approfondi	3-5 jours	Tous niveaux + recon + threat intel	Pré-certification ISO 27001, post-incident
Audit continu	Permanent	Monitoring + alertes	Programme de sécurité mature

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

Rôle	Responsabilité
Auditeur principal	Exécution technique, collecte de données, analyse
Super Admin client	Création du compte de service, délégation des droits
DPO	Validation du périmètre RGPD, approbation des accès
RSSI	Validation de la méthodologie, priorisation des risques
Direction	Approbation de l'audit, réception du rapport exécutif

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    │            │
│  │  Identités  │  │ Messagerie  │  │    Drive    │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
│                                                                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │    Apps     │  │  Appareils  │  │   Groupes   │            │
│  │   OAuth     │  │   Mobile    │  │  & Partages │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
│                                                                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐            │
│  │    Logs &   │  │  Calendar   │  │    Chat &   │            │
│  │  Alertes   │  │             │  │   Meet      │            │
│  └─────────────┘  └─────────────┘  └─────────────┘            │
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐ │
│  │              DNS & Sécurité Email (SPF/DKIM/DMARC)       │ │
│  └───────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
                              │
                 Périmètre étendu (OSINT)
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
  Sous-domaines          Threat Intel           Dark Web
  (crt.sh, Shodan)    (HIBP, Dehashed)      (IntelX, Flare)

2.2 Matrice de couverture par niveau

Niveau	Domaine	APIs requises	Impact potentiel
1	IAM & Authentification	Directory v1, Reports v1	Critique
2	Gmail & Messagerie	Gmail API, Directory v1	Critique
3	Google Drive	Drive API v3	Critique
4	DNS & Email	DNS (externe)	Élevé
5	Applications OAuth	Directory v1, Reports v1	Élevé
6	Appareils MDM	Directory v1 (devices)	Moyen
7	Groupes	Directory v1, Groups Settings	Moyen
8	Logs & Alertes	Reports v1, Alert Center	Élevé
9	Recon & Threat Intel	APIs externes	Variable
10	Conformité	Synthèse	Réglementaire

3. Prérequis et Infrastructure d'Audit

3.1 Compte requis côté client

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

Un compte Super Admin Google Workspace appartenant à l'organisation auditée — pour créer le Service Account et configurer la délégation
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
gcloud iam service-accounts keys create audit-key.json \
  --iam-account=audit-sa@audit-workspace-YYYYMMDD.iam.gserviceaccount.com

É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
gcloud services enable alertcenter.googleapis.com
gcloud services enable groupssettings.googleapis.com

É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,
https://www.googleapis.com/auth/admin.directory.device.mobile.readonly,
https://www.googleapis.com/auth/admin.directory.user.security,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.directory.customer.readonly,
https://www.googleapis.com/auth/apps.groups.settings,
https://www.googleapis.com/auth/gmail.settings.basic,
https://www.googleapis.com/auth/drive.readonly,
https://www.googleapis.com/auth/calendar.readonly,
https://www.googleapis.com/auth/apps.alerts

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

SCOPES = [
    "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.user.security",
    "https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly",
    "https://www.googleapis.com/auth/admin.directory.customer.readonly",
    "https://www.googleapis.com/auth/apps.groups.settings",
    "https://www.googleapis.com/auth/gmail.settings.basic",
    "https://www.googleapis.com/auth/drive.readonly",
    "https://www.googleapis.com/auth/calendar.readonly",
    "https://www.googleapis.com/auth/apps.alerts",
    "https://www.googleapis.com/auth/admin.directory.device.mobile.readonly",
]

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

def get_credentials(scopes=None):
    creds = service_account.Credentials.from_service_account_file(
        SERVICE_ACCOUNT_KEY,
        scopes=scopes or SCOPES,
        subject=ADMIN_EMAIL,
    )
    return creds

def get_directory_service():
    return build("admin", "directory_v1", credentials=get_credentials())

def get_reports_service():
    return build("admin", "reports_v1", credentials=get_credentials())

3.4 Prérequis techniques auditeur

Outil	Version min	Usage
Python	3.10+	Scripts d'audit
google-api-python-client	2.x	Clients APIs Google
google-auth	2.x	Authentification OAuth2
dnspython	2.x	Vérifications DNS
requests	2.x	APIs externes (HIBP, crt.sh)
rich	13.x	Affichage terminal enrichi

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

# Ou via Python si accès admin
import ntplib, ctypes, time
c = ntplib.NTPClient()
r = c.request('pool.ntp.org', version=3)
# Appliquer via SetLocalTime sur Windows

---