Conformité SOC 2 pour Google Workspace : ce qu'il faut savoir

Si votre organisation vise la conformité SOC 2 — et c'est le cas de la plupart des éditeurs de logiciels B2B à terme, car les clients le demandent — Google Workspace sera dans le périmètre. Il héberge des identités, des documents et des contrôles d'accès qui correspondent directement aux critères examinés par un auditeur. Cet article explique comment Workspace s'intègre à un programme SOC 2 et comment préparer le volet Workspace sans précipitation de dernière minute.

Une précision de vocabulaire dès le départ : SOC 2 est une *attestation* réalisée par un cabinet d'expertise-comptable indépendant, et non un badge que l'on s'attribue soi-même. Le résultat est un rapport établi par un auditeur, pas une étiquette auto-déclarée. Ce que vous pouvez faire en interne, c'est construire et démontrer les contrôles, et rassembler les preuves, afin que l'attestation se déroule sans accroc. C'est le sujet de cet article.

Un rapide point de repère sur SOC 2

SOC 2 évalue les contrôles d'une organisation de services au regard des Trust Services Criteria (TSC) : Security (toujours incluse, souvent appelée Common Criteria), et, en option, Availability, Processing Integrity, Confidentiality, et Privacy. Les critères Security — la série CC — sont ceux où Google Workspace intervient le plus.

Un rapport Type I évalue si les contrôles sont *conçus* de manière appropriée à un instant donné. Un rapport Type II évalue s'ils ont *fonctionné efficacement* sur une période (généralement de 3 à 12 mois). C'est le Type II que les clients demandent en général, ce qui a une implication importante : il vous faut des contrôles qui fonctionnent, et des preuves qu'ils ont fonctionné, tout au long de la période — pas seulement le jour de l'audit.

Où Google Workspace recoupe les critères

Plusieurs Common Criteria correspondent directement à des contrôles Workspace que vous manipulez déjà :

• CC6.1 — Contrôles d'accès logiques. Qui peut accéder aux informations protégées, et comment l'accès est limité aux utilisateurs autorisés. En termes Workspace : le provisionnement des comptes, l'application de la MFA, les contrôles de partage, et l'accès détenu par chaque identité, y compris les comptes externes et les comptes de service.
• CC6.2 — Enregistrement et autorisation. Les nouveaux utilisateurs sont enregistrés et autorisés avant que l'accès ne soit accordé ; l'accès est retiré lorsqu'il n'est plus nécessaire. L'hygiène joiner/mover/leaver relève de ce critère.
• CC6.3 — Moindre privilège et séparation des tâches. L'accès est fondé sur les rôles et limité au strict nécessaire. Les accès sur-privilégiés et la prolifération des droits d'administration constituent des constats contre ce critère.
• CC6.6 — Protection contre les menaces externes. La surface accessible de l'extérieur : liens publics, partages externes, et accès accordé à des identités extérieures à l'organisation.
• CC7.x — Surveillance et réponse aux incidents. Détecter les anomalies et réagir aux événements de sécurité. Savoir quand un partage ou un accès change, et être en mesure d'enquêter, appuie ces critères.

Inutile de mémoriser la numérotation. L'essentiel est que le travail quotidien sur Workspace — imposer la MFA, contrôler le partage, retirer les accès obsolètes, encadrer les applications tierces — *constitue* précisément la preuve de contrôle que recherche un auditeur.

Ce que les auditeurs demandent réellement

Les auditeurs ne veulent pas d'assurances ; ils veulent des preuves. Pour les contrôles liés à Workspace, attendez-vous à des demandes telles que :

• La preuve que la MFA est appliquée (la politique et son application effective, pas seulement « nous l'avons activée »).
• La liste des administrateurs et une justification pour chaque rôle privilégié.
• Des preuves de revues d'accès — que vous vérifiez périodiquement qui peut accéder aux données sensibles et que vous agissez sur ce que vous constatez.
• Des enregistrements du retrait des accès (deprovisioning) lorsque des employés quittent l'organisation.
• La configuration de partage et la manière dont le partage externe est contrôlé.
• Un historique montrant comment les constats de sécurité sont suivis jusqu'à leur résolution.

Le thème récurrent est un processus documenté et reproductible, avec une piste d'audit. Un contrôle qui existe mais ne laisse aucune trace est difficile à attester. Un contrôle qui s'exécute en continu et journalise ses constats est facile à attester.

Comment préparer le volet Workspace

1. Établir une base de référence de configuration. Documentez l'état attendu de vos paramètres d'administration — partage, validation en deux étapes, restrictions Marketplace, authentification des e-mails — et vérifiez la réalité par rapport à cette référence selon un calendrier défini. La dérive est l'ennemie d'un audit propre.
2. Effectuer des revues d'accès que vous pouvez justifier. Passez périodiquement en revue qui peut accéder aux données sensibles, y compris les identités externes et non humaines, et conservez le résultat. « Nous avons revu les accès trimestriellement, voici les enregistrements » est exactement ce que veut le CC6.3.
3. Renforcer et documenter le partage. Recoupez les critères CC6.1 et CC6.6 en contrôlant le partage public et externe et en étant capable de démontrer l'état actuel.
4. Suivre les constats jusqu'à leur résolution. Lorsque vous détectez une exposition, consignez-la, corrigez-la, et conservez la trace. Cela appuie les critères de surveillance et de remédiation.
5. Conserver un journal d'audit. Un enregistrement horodaté des actions pertinentes en matière de sécurité rend triviales les questions du type « qui a fait quoi, et quand ».

Tout cela recoupe largement les bonnes pratiques de sécurité Google Workspace en général — c'est bien là l'idée. SOC 2 n'est pas un projet distinct greffé après coup ; c'est votre pratique de sécurité, rendue lisible et prouvée.

Des preuves continues valent mieux que la course contre la montre de l'audit

Le mode d'échec classique consiste à traiter la conformité comme un événement : un mois frénétique de captures d'écran et de tableurs avant l'audit, répété chaque année. C'est stressant, source d'erreurs, et cela ne produit que des preuves ponctuelles qu'un auditeur Type II remettra à juste titre en question.

L'alternative est continue : maîtriser la posture toute l'année, générer les preuves comme sous-produit, et arriver à l'audit avec la piste déjà constituée. Un outil de gestion de la posture qui associe les constats aux critères SOC 2 et produit des preuves prêtes pour l'auditeur transforme la course contre la montre en un simple export.

Pièges courants dans le volet Workspace d'un audit

Quelques erreurs reviennent sans cesse et méritent d'être anticipées :

• Confondre « configuré » et « appliqué ». Activer une politique de validation en deux étapes n'équivaut pas à ce qu'elle s'applique à tous les comptes. Les auditeurs testent ce second point. Vérifiez que l'application tient à l'échelle de toute l'organisation — voir notre guide sur l'application de la MFA sur Google Workspace.
• Traiter les revues d'accès comme une simple case à cocher. « Nous revoyons les accès » sans enregistrements, sans périmètre défini, ni suivi, ne constitue pas une preuve. Conservez le résultat et démontrez que des mesures ont été prises suite aux constats.
• Oublier les identités non humaines. Les comptes de service et les agents IA détiennent eux aussi des accès, et un auditeur examinant le moindre privilège (CC6.3) n'acceptera pas « nous n'avons revu que les personnes ». Encadrez-les — voir détecter les agents IA à risque.
• Laisser la configuration dériver entre deux audits. Une base de référence propre en janvier et qui a dérivé d'ici juin produit un constat en Type II. C'est une vérification continue, et non un instantané annuel, qui permet de tenir la ligne.

La conformité est un sous-produit d'une bonne sécurité

Le recadrage le plus utile pour le volet Workspace de SOC 2 est de comprendre que vous ne construisez pas des contrôles *pour l'audit* — vous menez un programme de sécurité solide et laissez l'audit l'observer. Tout ce qu'un auditeur veut voir au titre des critères de contrôle d'accès est quelque chose que vous voudriez de toute façon : identité appliquée, partage contrôlé, accès tiers encadrés, et une base de référence de configuration maintenue. L'audit vous demande simplement de rendre cela lisible et prouvé.

Les équipes qui intègrent cette logique cessent de redouter le cycle annuel. Les contrôles fonctionnent toute l'année, les preuves s'accumulent comme sous-produit, et l'audit devient une revue d'un travail déjà accompli plutôt qu'un projet en soi. C'est aussi, en pratique, la différence entre courir après le temps et être prêt.

8200.dev associe la posture de votre Google Workspace aux familles de contrôles SOC 2, ISO 27001 et GDPR, et génère des dossiers de preuves que vous pouvez remettre à un auditeur — honnêtes, circonscrits à ce que nous observons réellement, jamais une allégation de conformité non fondée. En savoir plus sur notre fonctionnement ou sur nos propres pratiques de sécurité.

Vous préparez un audit ? Démarrez votre audit de sécurité gratuit et découvrez comment la posture de votre Google Workspace se positionne face aux critères de contrôle d'accès examinés par les auditeurs.