Le panneau de sécurité de Google Workspace : rôles, détection et e-mail

Un domaine Google Workspace a des dizaines d'interrupteurs de sécurité répartis dans le panneau d'administration, et le problème n'est presque jamais le manque de contrôles : c'est de ne pas savoir lesquels sont reliés entre eux. « Google Workspace Security », le quatrième cours de la série d'administration de Workspace sur Google Skills, les parcourt en dix-sept leçons de pratique guidée sur un domaine d'entraînement, avec des utilisateurs d'exemple et deux unités organisationnelles. Ce post suit ce parcours de bout en bout : qui peut quoi, ce que veille le Security Center, comment les applications et les appareils sont protégés, et ce qu'on fait au courrier.

flowchart LR
    A[Réglages et qui entre<br/>2SV, rôles, CAA] --> B[Veille<br/>Security Center et règles d'activité]
    B --> C[Apps et navigateur<br/>SAML, scopes, Chrome]
    C --> D[Appareils<br/>gestion mobile et partenaires endpoint]
    D --> E[E-mail<br/>SPF, DKIM, DMARC, filtrage]

Réglages communs : 2SV, apps et groupes

Le parcours démarre par le basique avec des détails qui passent inaperçus. Les codes de secours de 2-Step Verification fonctionnent avec un seul jeu actif à la fois : générer un nouveau jeu invalide automatiquement le précédent, y compris les codes que l'utilisateur avait créés par lui-même. L'accès des « apps moins sécurisées » se désactive par unité organisationnelle.

Les groupes de sécurité se créent en ajoutant l'étiquette « Security » à un groupe existant, et ce changement est permanent. Ils ont une limite déclarée : les comptes non-Google ne peuvent pas être ajoutés, car les pratiques de sécurité des fournisseurs externes ne peuvent pas être vérifiées. Et pour appliquer la 2SV à une partie seulement d'une unité organisationnelle sans la fragmenter en OUs, le motif est un groupe d'exception : on crée un groupe avec les utilisateurs exemptés, on applique la politique sur toute l'OU et on désactive l'application pour ce groupe, de sorte que le réglage s'applique à l'intersection OU ∩ groupe. Pour le cas inverse — n'appliquer qu'à un sous-ensemble —, on inverse : on applique pour le groupe et on désactive sur l'OU.

Qui peut quoi : rôles et accès selon le contexte

Les rôles d'administrateur viennent en deux saveurs. Les prédéfinis regroupent des privilèges pour des fonctions métier courantes ; les personnalisés permettent de combiner des privilèges concrets et vont jusqu'à 750 par organisation (l'exemple crée un rôle avec le privilège Carbon Footprint Reports). La recommandation est le principe du moindre privilège : seulement les privilèges dont le rôle a besoin. Les limites opérationnelles comptent : un rôle admet jusqu'à 20 utilisateurs et groupes par attribution, les changements peuvent mettre jusqu'à 24 heures à se propager, et personne ne peut se retirer un rôle à soi-même.

Context-Aware Access est l'autre jambe du contrôle d'accès : des niveaux définis par des attributs de contexte — identité, emplacement, état de sécurité de l'appareil et adresse IP — assignés à des applications concrètes. L'exemple crée le niveau « Device requirements » exigeant macOS ou iOS, uni avec un opérateur OR, et l'assigne à Google Vault avec un message personnalisé pour qui ne respecte pas : « Your device does not meet our requirement of being an iOS or macOS device ».

Ce qu'il voit et ce sur quoi il agit : Security Center

Le Security Center a trois pièces. Le security health compare la configuration du domaine à la ligne de base recommandée par Google, avec des filtres par application, pour voir quels réglages s'écartent du recommandé. Le security dashboard montre l'activité avec des données qui se mettent à jour toutes les 15 minutes. Et l'investigation tool permet de chercher dans des sources comme les Gmail messages avec des conditions (externe, domaine du destinataire, date), de regrouper les résultats par attribut comme Delivery status et d'exporter le tout vers un Sheet.

Sur cette visibilité se montent les règles d'activité, qui combinent une condition — si x arrive — avec des actions — alors faites y. L'exemple « Suspicious login rule » tourne sur les User log events : événement Suspicious login, seuil d'une occurrence par heure, action de forcer le changement de mot de passe et alerte vers l'Alert Center avec sévérité élevée et e-mail à un administrateur. Les états sont Active par défaut, Monitor pour relire les logs avant de faire appliquer la règle, et Inactive.

flowchart TD
    U[User log events] --> C{Condition : Suspicious login}
    C --> T{≥1 par heure ?}
    T -->|Oui| F[Forcer le changement de mot de passe]
    F --> L[Alert Center sévérité High + e-mail]
    T -->|Non| N[Aucune action]

Il y a trois limites à garder en tête. Les actions de remédiation automatiques sont exclusives aux éditions premium (Business Plus, Enterprise Standard et Enterprise Plus) ; les éditions basiques génèrent des alertes mais n'exécutent pas d'actions correctives, et il n'y a pas d'actions pour les événements Drive. Les règles analysent des données historiques de logs, pas des informations en temps réel des navigateurs, appareils ou messages. Et le seuil s'évalue sur le total de l'organisation, pas par utilisateur : une règle « suspendre après cinq tentatives échouées en une heure » est remplie par cinq échecs globaux dans cette heure et suspend tous les utilisateurs ayant au moins un échec.

Applications : SAML, scopes et niveaux de confiance

Le SSO avec SAML utilise Google comme fournisseur d'identité pour plus de 200 apps préintégrées ou des apps personnalisées : on télécharge les métadonnées, on remplace le domaine dans l'ACS URL, l'Entity ID et la Start URL, et le reste de la configuration (monter le certificat, compléter l'Entity ID et la SSO URL, activer l'app) se complète chez le fournisseur de service. Chaque profil admet jusqu'à deux certificats du SP, et certains services synchronisent en plus les utilisateurs avec le répertoire.

Pour les apps connectées, les scopes d'API définissent les permissions exactes et l'autorisation à trois pattes (3LO) délivre des tokens OAuth 2.0 à l'installation de l'app. L'administrateur active ou désactive des APIs et maintient une liste d'apps de confiance, avec trois niveaux : trusted, avec accès à tous les services Workspace, y compris les restreints ; specific Google data, qui ne peut demander que les scopes définis à la configuration de l'app ; et limited, seulement les services non restreints. Voici l'avertissement que la leçon répète : en bloquant un scope, les apps qui l'utilisaient cessent de fonctionner et leurs tokens sont révoqués. Les apps autorisées dans Marketplace, Android et iOS sont automatiquement de confiance.

Navigateur et appareils

Les politiques Chrome s'appliquent aux comptes et navigateurs inscrits, et sur les machines Windows, Mac et Linux inscrites elles s'appliquent même si l'utilisateur ne se connecte pas. L'installation forcée d'apps et extensions, de la Chrome Web Store ou de tiers, garantit que tous ont les outils nécessaires : les utilisateurs ne peuvent pas retirer ce qui est forcé, et ces éléments contournent les listes de blocage.

La gestion mobile basique est activée par défaut pour Android et iOS : exigences de mot de passe, gestion des applications, effacement des données corporatives, alertes et inventaire importé depuis un modèle CSV. Depuis la page de l'utilisateur, on exécute « Wipe Account », avec des états d'effacement qui apparaissent après la prochaine synchronisation, qui peut prendre jusqu'à trois heures sur certaines machines. L'avancée ajoute le chiffrement, des restrictions de l'écran de verrouillage et l'approbation obligatoire de l'administrateur pour l'inscription des appareils, et sur iOS elle exige un certificat APNs valide et une licence compatible.

Le pont avec le matériel corporatif est fermé par Endpoint Verification, une extension de Chrome qui collecte l'id de l'appareil, le numéro de série, le type et le système d'exploitation, la première et dernière synchronisation, et si l'appareil suit les politiques de l'organisation. S'il faut aller au-delà, la BeyondCorp Alliance intègre des partenaires comme Check Point, CrowdStrike, Jamf, Lookout, Microsoft Intune (bureau seulement) et Omnissa : leurs données d'appareils alimentent l'inventaire et les règles Context-Aware Access, avec une clarification importante — Google décline la responsabilité sur l'exactitude des données du partenaire.

L'e-mail : authentifier, filtrer et contenir

L'authentification du courrier repose sur trois enregistrements. SPF publie un seul enregistrement par domaine, pour éviter les conflits, qui fonctionne comme allowlist des serveurs émetteurs autorisés (v=spf1 include:_spf.google.com ~all). DKIM génère une paire de clés dans Gmail > Authenticate email et publie l'enregistrement google._domainkey, avec une activation prenant de 24 à 72 heures ; il ajoute une signature vérifiant que le courrier est parti du domaine et n'a pas été altéré. DMARC, sur l'enregistrement _dmarc avec p=none, indique aux serveurs récepteurs quoi faire des messages qui ne passent pas SPF ou DKIM et renvoie des rapports quotidiens de problèmes potentiels. Les trois se vérifient avec l'outil Check MX du Google Admin Toolbox.

Le filtrage de contenu travaille sur le courrier sortant avec des expressions avancées : l'exemple « Secure Project Jupiter » cherche « Jupiter » dans le corps du message et modifie le destinataire de l'enveloppe vers la boîte de Sam, avec la liste « Executive » exempte de la règle. Quand un message correspond à une règle de conformité, il y a trois issues : le rejeter avant qu'il n'atteigne le destinataire, le mettre en quarantaine pour révision administrative, ou le modifier (en-têtes, pièces jointes, sujet, destinataires). En entrée, l'e-mail avancé ajoute des filtres spam personnalisés, une quarantaine administrative, une liste de expéditeurs approuvés et une gateway par plage d'IP, avec denylist, allowlist et approved senders list comme personnalisation ; le scan spam de Gmail ne peut pas être désactivé et son dossier se vide à 30 jours.

Ce que ce parcours laisse et ce qui n'a pas été vérifié

Ce que cette carte montre, c'est que la sécurité de Workspace est une pile de couches qui se tiennent : le moindre privilège décide qui peut toucher quoi, Context-Aware Access décide depuis où, le Security Center veille et agit sur ce qui s'est déjà passé, les politiques Chrome et la gestion mobile ferment l'endpoint, et le courrier s'authentifie et se filtre dans les deux sens. Aucune couche ne remplace l'autre ; la règle d'activité qui force un changement de mot de passe ne sert à rien si le privilège était mal attribué, et inversement.

Ce qui n'a pas été vérifié : le cours inclut cinq quizzes qui n'ont pas été ouverts, donc aucune affirmation sur leurs réponses, et les chiffres et éditions décrits correspondent à la version du matériel téléchargée le 2026-10-12.

*Source : « Google Workspace Security », de Google Skills.*