Grand Guide · Cybersécurité
intermediaire
Guide Complet d'Audit de Sécurité Google Workspace
Guide complet d'audit de sécurité Google Workspace 2026 : IAM, DLP, Vault, Device Management — 10 niveaux de contrôle, scripts Apps Script inclus.
AN
Ayi NEDJIMI
Expert Cybersécurité & IA
53
min lecture
100%
Gratuit
FR
Français
2026
Édition
Grand Guide
Guide Complet d'Audit de Sécurité Google Workspace
Cybersécurité & IA
Ayi NEDJIMI
ayinedjimi-consultants.fr
✅ 100% Gratuit · Aucune inscription
📋 Aperçu du guide
📖 Sommaire
Ce que vous allez apprendre
Chapitre 1
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)
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 │ │
# ... (extrait — voir documentation officielle)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
# ... (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 = "[email protected]" # 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
| 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 rich3.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)---
Chapitre 2
Audit des identités, Super Admins, 2FA, emails de récupération, comptes inactifs. Audit Gmail : transferts automatiques, délégations, filtres de redirection et App Passwords.
Niveaux 1 & 2 — Les plus critiques
IAM/Auth et Gmail constituent 70% des vecteurs d'attaque réels
N1 — Identités & Auth
N2 — Gmail & Messagerie
CRITIQUE — À VÉRIFIER EN PREMIER
Priorités absolues de ce chapitre
- 2FA enforced sur tous les comptes sans exception
- Emails de récupération Super Admins = internes au domaine
- Aucun transfert automatique Gmail actif
- Aucun App Password (Less Secure App) actif
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)| Attribut API | Signification | Alerte si |
|---|---|---|
isAdmin | Super Admin | > 4 comptes |
isDelegatedAdmin | Admin délégué | Lister et justifier |
suspended | Compte suspendu | Présent sans offboarding |
isEnrolledIn2Sv | 2FA enrollée | False = CRITIQUE |
isEnforcedIn2Sv | 2FA obligatoire enforced | False = non conforme CIS |
lastLoginTime | Dernière connexion | > 90 jours = inactif |
recoveryEmail | Email de récupération | Externe = risque bypass 2FA |
recoveryPhone | Téléphone de récupération | Externe = risque SIM swap |
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)| Type 2FA | Résistance phishing | Recommandation |
|---|---|---|
| FIDO2 / Passkey / YubiKey | ✅ Totale | Obligatoire pour admins |
| TOTP (Google Authenticator) | ⚠️ Partielle | Vulnérable AITM |
| SMS OTP | ❌ Faible | Vulnérable SIM swap |
| Backup codes | ❌ Très faible | À usage unique uniquement |
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)| Type | Niveau | Raison |
|---|---|---|
@gmail.com, @outlook.com | 🔴 ÉLEVÉ | Grand public, souvent peu sécurisé |
@yahoo.fr, @hotmail.fr | 🔴 ÉLEVÉ | Breaches historiques massives (Yahoo 2016) |
| Domaine d'une autre entreprise | 🟠 MOYEN | Employé précédent ou freelance |
@domaine.com interne | ✅ OK | Contrôlé par l'organisation |
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)- 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)---
Chapitre 3
Audit des partages Google Drive (publics, externes, service accounts). Vérification SPF/DKIM/DMARC et blacklists. Inventaire et analyse des risques des tokens OAuth et applications tierces.
Niveaux 3, 4 & 5
Drive, DNS et applications OAuth tierces
N3 — Google Drive
N4 — DNS & Email
N5 — OAuth & Apps tierces
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)| Indicateur | Seuil d'alerte | Risque |
|---|---|---|
| Fichiers SQL/BDD | > 0 | Données production exposées |
| Fichiers anciens (> 3 ans) | > 30% | Violation Art. 5(1)(e) RGPD |
| Fichiers > 1 GB | Tout | Dump de données potentiel |
| Fichiers ".msg" Outlook | > 100 | Emails archivés hors contrôle |
| Noms évocateurs RH/paie | > 0 | Données personnelles sensibles |
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)| Mécanisme | Comportement | Niveau de protection |
|---|---|---|
-all (hard fail) | Emails non autorisés rejetés | ✅ Optimal |
~all (soft fail) | Emails marqués suspects | ⚠️ Insuffisant |
?all (neutral) | Aucune action | ❌ Inutile |
+all | Tout autorisé | 🔴 CRITIQUE — à corriger immédiatement |
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)Phase 1 (Observation) : p=none ; rua=mailto:[email protected]
↓ (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=reject7.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- Application avec un
clientIdinconnu ou non documenté - Scope
mail.google.comaccordé à 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 ?
---
Chapitre 4
Audit MDM et appareils mobiles. Gouvernance des groupes. Analyse des alertes Alert Center et logs de connexion. Reconnaissance passive via crt.sh, Shodan, Google Dorks et HIBP.
Niveaux 6, 7, 8 & 9
Appareils, groupes, journalisation et reconnaissance
N6 — Appareils MDM
N7 — Groupes
N8 — Journalisation & Alertes
N9 — Recon & Threat Intel
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)- 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 :| Contrôle | Standard | Pour admins |
|---|---|---|
| PIN/biométrie | Obligatoire (6+ chiffres) | Obligatoire (8+ chiffres) |
| Chiffrement | Obligatoire | Obligatoire |
| Mise à jour OS | Recommandée | Forcée sous 30 jours |
| Remote wipe | Activé | Activé + testé annuellement |
| Timeout verrouillage | 5 minutes | 2 minutes |
| Appareils rootés/jailbreakés | Bloqués | Bloqués |
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 :| Paramètre | Valeur recommandée | Risque si non configuré |
|---|---|---|
| Partage hors domaine | Désactivé ou approuvé | Fuite de données non contrôlée |
| "Anyone with link" | Désactivé pour non-admins | Fichiers publics non maîtrisés |
| Avertissement partage externe | Activé | Partages accidentels |
| Expiration des liens | 30-90 jours | Liens actifs indéfiniment |
| Domaines de confiance | Liste explicite | Partages vers n'importe qui |
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)- 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 :| Type d'alerte | Déclencheur | Priorité |
|---|---|---|
| Connexion suspecte | Toute connexion suspecte détectée | 🔴 Critique |
| Super Admin modifié | Ajout/suppression de Super Admin | 🔴 Critique |
| Transfert Gmail activé | Activation d'un forwarding | 🔴 Critique |
| Partage "anyone" créé | Fichier partagé publiquement | 🟠 Élevé |
| App OAuth autorisée | Nouvelle autorisation d'app | 🟠 Élevé |
| Compte suspendu | Suspension automatique (spam) | 🟠 Élevé |
| Réinitialisation 2FA admin | Tout admin | 🟠 Élevé |
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-domaine | Risque |
|---|---|
dev., staging., test.* | Environnements non sécurisés, PHP/frameworks obsolètes |
vpn., remote. | Points d'entrée réseau exposés |
admin., portal. | Interfaces d'administration exposées |
api.* | APIs potentiellement non authentifiées |
mail., webmail. | Clients mail alternatifs |
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)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)| Type de breach | Risque | Action |
|---|---|---|
| Stealer Logs (Naz.API, ALIEN TXTBASE) | 🔴 MAXIMAL | Mots de passe en clair potentiels — rotation immédiate |
| Credential stuffing lists | 🔴 CRITIQUE | Combinaisons email/password testées activement |
| Collection #1/#2/#3 | 🔴 CRITIQUE | Compilation massive de credentials |
| Exploit.in, Cit0day | 🔴 CRITIQUE | Bases de credentials actifs |
| LinkedIn Scraped | 🟡 MOYEN | Données publiques — risque spear-phishing |
| PDL Data Enrichment | 🟡 MOYEN | Données de contact — risque phishing |
| Deezer, Nitro, Canva | 🟡 MOYEN | Services grand public — réutilisation mot de passe |
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)- Leur rôle dans l'organisation (Super Admin = risque maximal)
- La présence d'un email de récupération externe
- Le type de breach (stealer log vs. scraping public)
Chapitre 5
Conformité RGPD article par article, NIS2, CIS Benchmark Google Workspace. Framework d'automatisation Python, structure du rapport, matrice de priorisation et annexes techniques complètes.
Niveau 10, Outillage & Conformité
RGPD, NIS2, CIS Benchmark, automatisation et rapport final
N10 — Conformité RGPD/NIS2
CIS Benchmark
Automatisation
Rapport & Annexes
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 :| Article | Principe | Ce qu'on vérifie |
|---|---|---|
| Art. 5(1)(e) | Limitation de la conservation | Fichiers anciens > 3 ans sans politique de purge |
| Art. 5(1)(f) | Intégrité et confidentialité | Fichiers publics, partages non contrôlés |
| Art. 9 & 32 | Données sensibles | Bulletins de paie, données médicales, RH dans Drive non chiffré |
| Art. 17 | Droit à l'effacement | Procédure offboarding documentée |
| Art. 25 | Privacy by design | Paramètres de partage par défaut restrictifs |
| Art. 28 | Sous-traitants | DPA avec Google, Zendesk, Ivalua et autres SaaS |
| Art. 32 | Sécurité du traitement | 2FA, chiffrement, transferts email |
| Art. 33 & 34 | Notification de violation | Procédure de réponse aux incidents documentée |
| Art. 35 | DPIA | Traitements à risque élevé identifiés |
| Art. 44-49 | Transferts internationaux | SaaS US — Privacy Shield remplacé, clauses contractuelles |
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 :
| Obligation NIS2 | Vérification Workspace | Outil d'audit |
|---|---|---|
| Politique de sécurité des SI | PSSI documentée et appliquée | Revue documentaire |
| Gestion des incidents (72h) | Alert Center + procédure d'escalade | Alert Center API |
| Continuité d'activité | PCA/PRA documenté | Revue documentaire |
| Sécurité chaîne d'approvisionnement | Apps OAuth validées, sous-traitants DPA | OAuth audit |
| Contrôle d'accès MFA résistant phishing | FIDO2 pour admins | Directory API |
| Chiffrement | Données sensibles isolées et chiffrées | Drive API |
| Journalisation et surveillance | SIEM + rétention logs | Reports API |
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ésUn 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
| Erreur | Cause | Solution |
|---|---|---|
invalid_grant | Horloge désynchronisée | Resynchroniser NTP |
unauthorized_client | Scope absent de la délégation | Ajouter le scope dans admin.google.com |
insufficientPermissions | API non activée dans GCP | Activer l'API dans Cloud Console |
notACalendarUser | Utilisateur sans Calendar | Ignorer — pas une erreur de sécurité |
UnicodeEncodeError | Terminal Windows cp1252 | Utiliser python -X utf8 ou PYTHONUTF8=1 |
403 Forbidden | Service Account sans impersonation | Vérifier la Domain-Wide Delegation |
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)| Score | Niveau | Signification |
|---|---|---|
| 90-100 | ✅ Excellent | Posture mature, risques résiduels mineurs |
| 75-89 | 🟡 Bon | Bonne base, quelques gaps à combler |
| 60-74 | 🟠 Acceptable | Risques notables — roadmap requise |
| 40-59 | 🔴 Insuffisant | Vulnérabilités significatives — actions urgentes |
| < 40 | 🔴 Critique | Posture dangereuse — intervention immédiate |
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, formation15.4 Chemins d'attaque types
Kill Chain 1 — Exfiltration via forwarding GmailPhishing 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, contractuelEmail 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 AdminEmail 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 passeClé 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
| CIS ID | Contrôle | Méthode de vérification | Criticité |
|---|---|---|---|
| 1.1.1 | ≤ 4 Super Admins | users.list + filtre isAdmin=true | Haute |
| 1.1.2 | Comptes admin dédiés | Vérifier si les admins ont des emails dédiés non-quotidiens | Haute |
| 1.1.3 | 2FA obligatoire (enforced) | Attribut isEnforcedIn2Sv sur tous les comptes | Haute |
| 1.1.4 | Clés FIDO2 pour Super Admins | Absence de clé hardware = non conforme | Haute |
| 1.1.5 | Email récupération interne | recoveryEmail doit se terminer par @domaine.com | Haute |
| 1.1.6 | Politique mot de passe min. 12 car. | admin.google.com → Sécurité → Mots de passe | Moyenne |
| 1.1.7 | Expiration mots de passe désactivée si MFA fort | Dépend de la politique de mot de passe | Faible |
| 1.2.1 | Context-Aware Access pour admins | admin.google.com → Sécurité → Context-Aware Access | Haute |
Section 2 — Google Drive
| CIS ID | Contrôle | Méthode de vérification | Criticité |
|---|---|---|---|
| 2.1 | Restreindre partage hors domaine | Paramètres Drive dans admin.google.com | Haute |
| 2.2 | Désactiver "Anyone with link" | API Drive, permissions type=anyone | Haute |
| 2.3 | Avertissement avant partage externe | Paramètre admin.google.com | Moyenne |
| 2.4 | Expiration automatique des liens | Paramètre global Drive | Moyenne |
| 2.5 | Audit Drive régulier documenté | Processus organisationnel | Faible |
| 2.6 | DLP sur données sensibles | Google DLP ou solution tierce | Haute |
Section 3 — Gmail
| CIS ID | Contrôle | Méthode de vérification | Criticité |
|---|---|---|---|
| 3.1 | Désactiver transfert automatique | API Gmail, getAutoForwarding() | Critique |
| 3.2 | Désactiver délégation de boîte | API Gmail, delegates().list() | Haute |
| 3.3 | Anti-spam/phishing renforcé | Paramètres Gmail avancés | Haute |
| 3.4 | SMTP relay authentifié | admin.google.com → Gmail → Routing | Moyenne |
| 3.5 | Désactiver Less Secure Apps | API, asps().list() | Haute |
Section 4 — Sécurité Email DNS
| CIS ID | Contrôle | Méthode | Criticité |
|---|---|---|---|
| 4.1 | SPF -all (hard fail) | dns.resolver.resolve(domain, "TXT") | Haute |
| 4.2 | DKIM configuré (2048 bits) | dns.resolver.resolve("google._domainkey.domain", "TXT") | Haute |
| 4.3 | DMARC p=reject | dns.resolver.resolve("_dmarc.domain", "TXT") | Critique |
| 4.4 | DMARC reporting (rua) | Présence rua= dans l'enregistrement | Moyenne |
| 4.5 | MX uniquement Google | Vérifier qu'aucun MX parasite n'existe | Haute |
Section 5 — Applications Tierces
| CIS ID | Contrôle | Méthode | Criticité |
|---|---|---|---|
| 5.1 | Liste blanche d'applications | admin.google.com → Sécurité → API Controls | Haute |
| 5.2 | Bloquer apps non vérifiées | Paramètre admin.google.com | Haute |
| 5.3 | Revue trimestrielle des OAuth | Processus organisationnel | Moyenne |
| 5.4 | Alertes nouvelles autorisations OAuth | Alert Center config | Haute |
Section 6 — Appareils Mobiles
| CIS ID | Contrôle | Méthode | Criticité |
|---|---|---|---|
| 6.1 | MDM activé et enforced | mobiledevices().list() | Haute |
| 6.2 | Chiffrement obligatoire | Attribut deviceCompromisedStatus | Haute |
| 6.3 | PIN biométrique obligatoire | Politique MDM | Haute |
| 6.4 | Remote wipe disponible | Fonctionnalité MDM Workspace | Moyenne |
Section 7 — Groupes
| CIS ID | Contrôle | Méthode | Criticité |
|---|---|---|---|
| 7.1 | Pas de membres externes non justifiés | members().list() par groupe | Haute |
| 7.2 | Chaque groupe a un owner | Vérifier role=OWNER dans membres | Moyenne |
| 7.3 | Restriction création groupes aux admins | Paramètre admin.google.com | Faible |
Section 8 — Journalisation
| CIS ID | Contrôle | Méthode | Criticité |
|---|---|---|---|
| 8.1 | Logs d'audit activés | Reports API accessible | Haute |
| 8.2 | Rétention ≥ 1 an | Google Vault ou export SIEM | Haute |
| 8.3 | Alertes sur événements critiques | Alert Center configuration | Haute |
| 8.4 | Export logs vers SIEM | BigQuery, Chronicle, Splunk | Haute |
| 8.5 | Procédure réponse incidents | Processus organisationnel documenté | Haute |
17. Annexes Techniques
Annexe A — Scopes OAuth par module d'audit
| Module | Scopes requis |
|---|---|
| Utilisateurs & IAM | admin.directory.user.readonly, admin.directory.rolemanagement.readonly |
| Gmail forwarding/delegation | gmail.settings.basic (par utilisateur impersonifié) |
| Google Drive | drive.readonly |
| Tokens OAuth | admin.directory.user.security |
| Appareils MDM | admin.directory.device.mobile.readonly |
| Groupes | admin.directory.group.readonly, apps.groups.settings |
| Logs admin/connexion | admin.reports.audit.readonly |
| Alert Center | apps.alerts |
| Calendriers | calendar.readonly (par utilisateur impersonifié) |
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)
- [ ] 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é
- [ ] Aucun transfert automatique actif
- [ ] Aucune délégation externe
- [ ] Aucun App Password actif
- [ ] Filtres Gmail avec actions de redirection revus
- [ ] 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)
- [ ] SPF
-all(hard fail) - [ ] DKIM actif (2048 bits recommandé)
- [ ] DMARC
p=rejectavec reporting - [ ] IP MX non listées sur blacklists
- [ ] Volume de tokens par utilisateur
- [ ] Scopes accordés (Gmail complet, Drive complet = CRITIQUE)
- [ ] Applications AI avec accès données d'entreprise
- [ ] Sous-domaines via crt.sh
- [ ] Serveurs exposés (Shodan)
- [ ] Emails compromis (HIBP)
- [ ] Emails de récupération dans stealer logs
- [ ] 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
| Risque | Description | Gravité |
|---|---|---|
| Espaces publics | Un espace Google Chat ouvert à tous les utilisateurs peut contenir des informations sensibles | 🟠 ÉLEVÉ |
| Bots non autorisés | Des bots OAuth peuvent accéder aux messages et répondre automatiquement | 🔴 CRITIQUE |
| Partage de fichiers hors DLP | Les pièces jointes partagées dans Chat contournent les règles DLP Drive | 🟠 ÉLEVÉ |
| Historique non maîtrisé | Par défaut, l'historique des messages est conservé indéfiniment | 🟡 MOYEN |
| Espaces avec membres externes | Des espaces peuvent être partagés avec des utilisateurs hors domaine | 🟠 ÉLEVÉ |
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ésD.3 Audit Google Meet
| Contrôle | Paramètre | Risque si non configuré |
|---|---|---|
| Réunions externes | Qui peut rejoindre sans authentification | Participants non autorisés |
| Enregistrement | Où sont stockés les enregistrements | Fuites de réunions confidentielles |
| Transcriptions | Qui peut activer les transcriptions | Données sensibles transcrites et stockées |
| Partage d'écran | Restrictions | Données affichées par erreur enregistrées |
| Lobby (salle d'attente) | Activé ou non | Accès direct sans validation hôte |
---
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
| Solution | Mécanisme | Avantages | Inconvénients |
|---|---|---|---|
| Google Chronicle | Export natif Workspace | Intégration native, UEBA inclus | Coût Chronicle |
| BigQuery | Export via Cloud Logging | Flexible, SQL | Pas d'alertes natives |
| Splunk | App Google Workspace for Splunk | Écosystème Splunk | Complexité configuration |
| Microsoft Sentinel | Connecteur Google Workspace | Unifié si hybrid | Latence |
| Elastic SIEM | Logstash Google Workspace | Open source | Maintenance |
| Script Python custom | Reports API en polling | Gratuit, flexible | Pas temps réel |
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
| Maturité | Capacités | Indicateurs |
|---|---|---|
| Niveau 0 | Aucune surveillance | Pas de SIEM, alertes manuelles |
| Niveau 1 | Logs collectés | Rétention > 1 an, accès ponctuel |
| Niveau 2 | Alertes basiques | Alert Center + quelques règles SIEM |
| Niveau 3 | Détection active | Règles UEBA, corrélation inter-sources |
| Niveau 4 | SOC mature | SOAR, réponse automatisée, Threat Hunting |
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 :
| Paramètre | Valeur recommandée | CIS |
|---|---|---|
| Longueur minimale | 12 caractères | CIS 1.1.6 |
| Complexité | Activée (majuscule, chiffre, symbole) | Bonne pratique |
| Réutilisation | Bloquer les 10 derniers | Bonne pratique |
| Expiration | Désactivée si MFA fort en place | CIS 1.1.7 |
| Force du mot de passe | Indicateur activé | Informationnel |
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
| IoC | Signal | Priorité |
|---|---|---|
| Forwarding Gmail activé vers domaine externe | Log admin CHANGE_MAIL_FORWARDING_SETTING | 🔴 Critique |
| Connexion depuis pays jamais vu | Log login + geoloc | 🔴 Critique |
| Token OAuth accordé à app inconnue | Log token avec clientId inconnu | 🔴 Critique |
| Téléchargement massif Drive | Logs Drive > N fichiers en < 1h | 🔴 Critique |
| Nouveau Super Admin ajouté sans ticket | Log admin ASSIGN_ROLE | 🔴 Critique |
| Réinitialisation 2FA sur compte admin | Alert Center + log admin | 🟠 Élevé |
| Partage "anyone" sur fichier sensible | Log Drive permission change | 🟠 Élevé |
| Service account ajouté au Drive | Permissions Drive type=serviceAccount | 🟠 Élevé |
| Connexion depuis IP Tor ou VPN connu | Log login + threat intel | 🟠 Élevé |
| Volume anormal d'emails envoyés | Reports usage API | 🟡 Moyen |
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é :
| Contrôle | Poids | Raison |
|---|---|---|
| 2FA enforced sur tous les comptes | 15 pts | Prévention account takeover massive |
| Aucun transfert Gmail actif | 15 pts | Exfiltration en temps réel |
| Emails récup Super Admins internes | 12 pts | Vecteur takeover compte le plus élevé |
| DMARC p=reject | 10 pts | Protection usurpation identité email |
| Aucun fichier public ("anyone") | 10 pts | Données exposées sans contrôle |
| Gouvernance OAuth (whitelist) | 8 pts | Consent phishing |
| SPF hard fail (-all) | 7 pts | Complémentaire DMARC |
| DKIM 2048 bits | 5 pts | Intégrité emails |
| Groupes sans membres externes | 5 pts | Fuite d'information via groupes |
| Logs 1 an + SIEM | 5 pts | Forensics et détection |
| MDM actif et enforced | 4 pts | Appareils non gérés |
| Context-Aware Access | 4 pts | Contrôle contextuel |
H.2 Comparaison sectorielle
| Secteur | Score moyen observé | Maturité typique |
|---|---|---|
| Finance / Banque | 72/100 | Élevée — régulation stricte |
| Santé | 58/100 | Moyenne — effort RGPD récent |
| ESN / IT | 61/100 | Variable — souvent focalisé technique mais pas gouvernance |
| Industrie | 49/100 | Faible — Workspace outil récent |
| Associations / ONG | 35/100 | Très faible — ressources limitées |
| Startups (< 50 pers.) | 42/100 | Faible — croissance rapide, sécurité en retard |
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
| Ressource | URL | Usage |
|---|---|---|
| CIS Benchmark Google Workspace | cisecurity.org | Référentiel de contrôles |
| MITRE ATT&CK for Enterprise | attack.mitre.org | Techniques d'attaque |
| Google Admin SDK Docs | developers.google.com | Documentation API |
| HIBP API | haveibeenpwned.com/API | Vérification breaches |
| Have I Been Pwned Domain | haveibeenpwned.com/DomainSearch | Vérification par domaine |
| crt.sh | crt.sh | Certificate Transparency |
| Shodan InternetDB | internetdb.shodan.io | Exposition Internet (gratuit) |
| IntelligenceX | intelx.io | Darknet/leaks |
| ANSSI — Guide sécurité GSuite | ssi.gouv.fr | Recommandations françaises |
| Google Workspace Security Checklist | workspace.google.com/security | Checklist officielle Google |
Annexe E — Modèle de feuille de route
| ID | Action | Priorité | Effort | Impact | Responsable | Délai |
|---|---|---|---|---|---|---|
| R-01 | Désactiver transfert Gmail actif | 🔴 P1 | Faible | Critique | Admin IT | J+0 |
| R-02 | Retirer emails récup externes (stealer logs) | 🔴 P1 | Faible | Critique | Admin IT | J+0 |
| R-03 | Révoquer service accounts Drive externes | 🔴 P1 | Moyen | Critique | DSI | J+2 |
| R-04 | Supprimer fichiers publics | 🔴 P1 | Faible | Élevé | Admin IT | J+3 |
| R-05 | Désactiver forwarding Gmail globalement | 🔴 P1 | Faible | Critique | Admin IT | J+3 |
| R-06 | Réduire Super Admins à 3 max | 🟠 P2 | Moyen | Élevé | RSSI + DSI | J+7 |
| R-07 | SPF -all (hard fail) | 🟠 P2 | Faible | Élevé | Admin IT | J+7 |
| R-08 | Créer comptes admin dédiés | 🟠 P2 | Moyen | Élevé | DSI | J+14 |
| R-09 | Activer approbation OAuth | 🟠 P2 | Moyen | Élevé | Admin IT | J+14 |
| R-10 | Révoquer tokens AI sur comptes sensibles | 🟠 P2 | Faible | Élevé | Admin IT | J+7 |
| R-11 | Assigner owners aux groupes orphelins | 🟡 P3 | Faible | Moyen | Admin IT | J+14 |
| R-12 | Procédure offboarding documentée | 🟡 P3 | Moyen | Moyen | RH + DSI | J+30 |
| R-13 | Déployer YubiKeys pour Super Admins | 🟡 P3 | Élevé | Critique | RSSI | J+45 |
| R-14 | Context-Aware Access (restriction géo) | 🟡 P3 | Élevé | Élevé | Admin IT | J+45 |
| R-15 | Activer Google Vault | 🔵 P4 | Élevé | Moyen | DSI | J+60 |
| R-16 | Configurer export logs SIEM | 🔵 P4 | Élevé | Élevé | SOC | J+90 |
| R-17 | Règles DLP sur données sensibles | 🔵 P4 | Élevé | Élevé | RSSI | J+90 |
| R-18 | Formation sécurité utilisateurs | 🔵 P4 | Moyen | Élevé | RSSI + RH | J+60 |
| R-19 | Revue trimestrielle OAuth | 🔵 P4 | Faible | Moyen | Admin IT | Récurrent |
| R-20 | Audit Drive annuel documenté | 🔵 P4 | Moyen | Moyen | DSI | Récurrent |
---
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 internesConclusion
Ce guide opérationnel constitue une base de référence. Pour aller plus loin avec un accompagnement personnalisé, contactez notre équipe.
Besoin d'un accompagnement expert ?
Nous contacterPlongez dans le guide complet
Lecture en ligne avec sommaire interactif, pagination par chapitre et navigation rapide. Ou téléchargez le PDF.
Besoin d'un accompagnement expert ?
Audit, conseil, formation — devis sous 24h.