Réponse courte

Une agence SEO en marque blanche doit traiter chaque client comme une frontière d’autorisation, pas comme un dossier dans une interface commune. Appliquez le privilège minimal, des comptes nominatifs, une séparation vérifiée à chaque requête, des liens de partage bornés, un journal d’accès, une durée de conservation et une révocation testée. La marque blanche change l’apparence et la chaîne contractuelle ; elle ne réduit ni le RGPD, ni la responsabilité d’un mauvais accès.

À retenir

  • Masquer le nom d’un client n’est pas l’isoler : l’autorisation doit être vérifiée côté serveur pour chaque objet.
  • Les identifiants partagés empêchent l’attribution et retardent la révocation.
  • Search Console et Analytics offrent des rôles ; commencez par le plus faible réellement suffisant.
  • Cartographiez responsable de traitement, sous-traitants, finalités, lieux, conservation et suppression avant l’onboarding.
  • Ne présentez jamais une fonctionnalité produit comme une garantie de sécurité sans preuve technique et contractuelle.

Le modèle de menace d’une agence multi-client

Une agence concentre des données utiles : requêtes, performances, revenus, calendriers, contenus non publiés, accès CMS et stratégie concurrentielle. En marque blanche, un prestataire peut travailler pour le client final sans relation directe, ce qui ajoute des acteurs, des exports et des canaux de partage.

Les menaces les plus probables ne sont pas toutes sophistiquées :

  • un lien de rapport transféré au mauvais destinataire ;
  • un utilisateur autorisé sur le client A qui modifie l’identifiant de l’URL et voit le client B ;
  • un export contenant plusieurs clients ;
  • une clé API stockée dans un tableur ou un ticket ;
  • un ancien freelance dont le compte reste actif ;
  • une automatisation publiant avec le mauvais profil de marque ;
  • des données personnelles conservées « au cas où » sans échéance ;
  • un fournisseur secondaire absent de la documentation contractuelle.

L’OWASP classe la rupture d’autorisation au niveau objet parmi les principaux risques API. Le contrôle ne consiste pas à rendre les identifiants difficiles à deviner : le serveur doit vérifier que l’identité courante peut agir sur l’objet demandé.

Classification minimale des données

Classe Exemples SEO Accès Conservation Contrôle supplémentaire
Publique SERP publique, page publiée Équipe autorisée Selon besoin métier Provenance et date
Interne brief, calendrier, diagnostic Équipe du compte Durée du contrat + politique Partage restreint
Confidentielle conversions, marges, requêtes stratégiques Rôles nommés Minimum justifié Journal et export contrôlé
Secret jeton OAuth, clé API, secret CMS Système/service nécessaire Rotation et révocation Coffre de secrets, jamais dans les logs
Donnée personnelle email, identifiant, lead, comportement Finalité documentée Durée définie Base légale, droits, minimisation

La classification dépend du contexte et de la réglementation. Une requête apparemment anonyme peut devenir sensible lorsqu’elle est reliée à un utilisateur ou à un secteur réglementé.

Procédure en douze étapes

1. Cartographier acteurs et responsabilités

Identifiez le client final, l’agence principale, le prestataire en marque blanche, les logiciels et les sous-traitants. Documentez qui détermine les finalités, qui traite les données et qui répond aux demandes. Le RGPD distingue responsable de traitement et sous-traitant ; l’étiquette contractuelle ne suffit pas si la pratique dit autre chose.

2. Tenir un inventaire de données

Pour chaque source : catégorie, finalité, client, propriétaire, pays/région, accès, sous-traitant, conservation, suppression et export. Une donnée dont la finalité est inconnue ne doit pas être collectée par défaut.

3. Définir une frontière client unique

Toute ressource doit porter un identifiant client immuable. Les bases, objets, fichiers, caches, jobs et logs doivent l’utiliser. Ne déduisez pas le client à partir d’un nom de domaine libre ou d’une marque saisie dans un prompt.

4. Vérifier l’autorisation à chaque accès

La règle est : utilisateur authentifié + rôle + appartenance au client + permission sur l’action + état du contrat. Testez lecture, écriture, export, partage et administration. Refusez par défaut.

5. Utiliser des comptes nominatifs et le privilège minimal

Invitez chaque personne avec son identité professionnelle. Activez l’authentification multifacteur lorsque disponible. Évitez les comptes « agence@ » partagés. Pour Search Console et Analytics, choisissez le rôle suffisant et revoyez-le après la mission.

6. Gérer OAuth et les secrets

Demandez les scopes (autorisations OAuth) minimaux. Stockez les jetons dans un système de secrets, chiffrez-les selon l’architecture validée, excluez-les des logs et prévoyez rotation et révocation. Un accès Analytics en lecture seule ne couvre pas un CMS : chaque intégration possède son propre risque.

7. Séparer les environnements et les sorties

Utilisez des configurations de test distinctes. Chaque export et notification doit afficher le client source avant envoi. Les modèles d’email, logos, domaines, expéditeurs et voix de marque doivent être choisis par une configuration autorisée, pas par la dernière valeur en mémoire.

8. Concevoir les liens de partage

Un lien public permanent vers un rapport confidentiel est une fuite différée. Préférez authentification, expiration, audience définie, possibilité de révocation et journal. Si un téléchargement est nécessaire, marquez le client et minimisez les colonnes.

9. Journaliser sans recopier les secrets

Enregistrez acteur, client, action, objet, résultat, date et origine utile. Ne journalisez pas les tokens, mots de passe, contenu personnel intégral ou prompts confidentiels sans nécessité. Protégez les logs contre la modification et définissez leur durée.

10. Définir rétention et suppression

Le principe de minimisation du RGPD demande des données adéquates, pertinentes et limitées à ce qui est nécessaire. Écrivez une durée par catégorie, une exception légale et une procédure de suppression vérifiable, sauvegardes comprises.

11. Préparer l’incident

Définissez détection, qualification, confinement, preuve, notification, correction et retour d’expérience. Un mélange de clients exige d’abord de couper le chemin affecté, préserver les journaux et déterminer exactement quelles personnes et données sont concernées.

12. Tester l’offboarding

À la fin : retirer les utilisateurs, révoquer OAuth et clés, désactiver publications, transférer les actifs, supprimer selon le contrat, conserver la preuve et vérifier les sous-traitants. Faites ce test avant le premier départ réel.

Matrice de contrôles et de tests

Contrôle Test positif Test négatif Preuve attendue
Lecture client Membre A lit une ressource A Membre A demande ressource B 200 puis 403/404 contrôlé
Export Export A contient uniquement A Requête avec filtre B injecté Fichier borné, événement journalisé
Publication CMS Rôle éditeur publie une page autorisée Rôle analyste tente une publication Action puis refus
Lien partagé Destinataire autorisé avant expiration Lien expiré ou révoqué Accès puis refus
Révocation OAuth Appel fonctionne avant retrait Même appel après retrait Échec d’autorisation
Job automatique Job avec tenant_id valide Job sans client ou mauvais client Exécution puis rejet
Marque blanche Logo/domaine/expéditeur du client A Gabarit B injecté Sortie A puis blocage
Suppression Objet et index actifs retirés Récupération non autorisée Rapport de suppression

Exemple travaillé : un rapport exposé par identifiant

Exemple fictif. Une agence envoie au client A un lien /reports/1042. Un collaborateur remplace 1042 par 1043 et voit le rapport du client B. Les identifiants n’étaient pas secrets, mais le problème racine est l’absence de contrôle d’autorisation sur l’objet.

Le « correctif » consistant à utiliser un UUID plus long ne suffit pas. L’équipe :

  1. désactive les liens publics ;
  2. conserve les journaux et identifie les rapports consultables ;
  3. vérifie les obligations de notification avec le responsable approprié ;
  4. ajoute une requête bornée par utilisateur et client ;
  5. refuse par défaut les objets hors périmètre ;
  6. ajoute des tests inter-clients pour lecture, export et partage ;
  7. révoque les anciens liens ;
  8. documente l’incident et la rétention.

Le test de non-régression doit créer deux clients et deux rôles, puis essayer toutes les combinaisons interdites. Tester uniquement le parcours autorisé ne prouve pas l’isolation.

Score de risque interne

Utilisez une formule simple pour ordonner les contrôles :

Risque priorisé = impact × vraisemblance × exposition × difficulté de détection.

Notez chaque facteur sur une échelle interne documentée. Le score ne remplace pas une obligation légale : un risque de violation de données ou de frontière client peut rester bloquant même si sa fréquence estimée est faible.

Ce que les données prouvent et ne prouvent pas

Le RGPD et les guides de la CNIL établissent des principes et recommandations de sécurité, minimisation, droits et relations avec les sous-traitants. Ils ne certifient pas votre implémentation. Une politique signée ne prouve pas que l’API vérifie l’appartenance client.

OWASP fournit une taxonomie et des scénarios de risque ; ce n’est ni un audit de SEOryon ni une preuve d’incident. La documentation Google décrit les rôles et OAuth de ses services ; elle ne couvre pas les CMS, exports ou prestataires de votre chaîne.

Une question communautaire sur le « problème du portail client » montre une demande qualitative d’outillage. Elle ne valide aucune solution citée dans le fil et ne mesure pas la fréquence des incidents.

Échecs fréquents et conditions d’arrêt

  • Compte partagé : arrêter l’accès et créer des identités nominatives.
  • Client déterminé par un paramètre modifiable : exiger la portée serveur.
  • Secret dans un log ou ticket : révoquer, nettoyer selon procédure et enquêter.
  • Export sans compteur par client : bloquer la fonction jusqu’au test.
  • Sous-traitant inconnu : suspendre le transfert et clarifier contrat/localisation.
  • Suppression non testée : ne pas promettre un délai que l’architecture ne peut prouver.
  • Publication automatique avec mauvaise marque : couper le job et auditer toutes les sorties du lot.
  • Présumer que « lecture seule » signifie sans risque : les données lues peuvent rester hautement confidentielles.
  • Présumer une certification ou un chiffrement non documenté : demander la preuve actuelle avant toute affirmation commerciale.

Actif réutilisable : registre accès-données-révocation

Maintenez une ligne par autorisation : client, personne/service, système, rôle, scopes, finalité, approbateur, date d’octroi, dernière utilisation, date de revue, date de révocation et preuve. Reliez-la à une ligne de données : catégorie, lieu, sous-traitant, conservation et suppression.

Deux indicateurs sont utiles :

  • Taux de revue à jour = accès revus dans la fenêtre ÷ accès actifs ;
  • Délai de révocation = date de révocation effective − date de fin d’autorisation.

Ne transformez pas 100 % de revue en preuve de sécurité globale. Cela prouve seulement que ce contrôle a été exécuté selon sa définition.

Comment SEOryon intervient

Les fonctions publiques vérifiées indiquent que SEOryon utilise Search Console et Analytics en lecture seule et peut publier vers plusieurs CMS. La lecture seule réduit le type d’action possible sur ces deux sources ; elle ne rend pas les données non sensibles. La publication CMS implique par nature une autorisation distincte à cadrer.

Aucune affirmation supplémentaire sur chiffrement, SSO, localisation, certifications, journaux, isolation multi-tenant ou délais de suppression ne doit être ajoutée à cette page sans documentation publique vérifiable et actuelle. L’agence doit examiner les paramètres, le contrat, les sous-traitants et les tests de son propre déploiement.

Exercice mesurable

Créez deux clients de test, deux utilisateurs et trois rôles. Exécutez la matrice lecture/écriture/export/partage/publication, puis simulez un départ. L’exercice est réussi si :

  1. toutes les combinaisons inter-clients échouent ;
  2. aucun secret n’apparaît dans les journaux ;
  3. les liens révoqués cessent de fonctionner ;
  4. OAuth et CMS sont retirés dans le délai interne ;
  5. un rapport de suppression et de transfert est produit ;
  6. une autre personne peut reproduire les tests.

Parcours recommandé

FAQ

La marque blanche rend-elle l’agence responsable des données du client final ?

La responsabilité dépend des rôles et traitements réels, pas seulement du logo affiché. Cartographiez responsable de traitement, sous-traitants et instructions, puis faites valider le cadre juridique adapté.

Peut-on partager un compte Search Console entre consultants ?

Évitez-le. Utilisez des comptes nominatifs avec le rôle minimal, une revue et une révocation. Un compte partagé empêche d’identifier précisément l’acteur.

Un accès Analytics en lecture seule est-il sans risque ?

Non. Il peut exposer performances, conversions et données commerciales. La lecture seule limite les modifications, pas la confidentialité ni l’exfiltration.

Comment prouver l’isolation entre clients ?

Testez les parcours interdits : lecture, modification, export, cache, recherche, job, lien partagé et journal. Une interface qui masque les autres clients ne suffit pas.

Que faut-il supprimer à la fin d’un contrat ?

Accès, tokens, clés, partages, jobs et données selon la finalité, le contrat, les obligations légales et la politique de sauvegarde. Conservez une preuve sans conserver inutilement le contenu supprimé.

Références

Note de méthode et de mise à jour

Ce guide fournit des contrôles techniques et organisationnels généraux, pas un avis juridique ni un audit de produit. Revoir la page lors d’un changement réglementaire, des rôles Google, des intégrations publiques SEOryon, des sous-traitants ou de l’architecture multi-client.